No, on our shared hosting services you will not be able to run any custom executable, services, COM objects or install any 3rd party software, components etc. This restriction is enforced at the operating system and IIS level to prevent unauthorized code execution, maintain consistent performance across all accounts, and eliminate the risk of one customer's custom software impacting others on the same server. Attempts to bypass it through FTP uploads or application code will fail with permission or execution errors.

If you require custom configurations, or any of the above items we recommend that you check-out our VPS or Dedicated server offerings. These plans remove the multi-tenant constraints and give you the isolation and control required for specialized Windows and .NET workloads that depend on custom runtime elements.

#Why These Restrictions Exist on Shared Hosting

Shared hosting places dozens or hundreds of websites on a single Windows server running IIS and supporting .NET Framework versions. In this model, the hosting provider must lock down administrative functions, registry access, and executable permissions. Allowing custom executables could introduce malware, resource exhaustion from poorly written services, or conflicts with the pre-configured environment. COM objects, which rely on registry entries and system-wide registration, break the isolation boundaries that keep customer sites separate. The same applies to third-party components that require MSI installers, GAC registration, or Windows service creation. These controls ensure predictable uptime and security but limit what can be deployed.

#Specific Items You Cannot Install or Run

  • Custom executable files (.exe, .bat, or compiled binaries) that run outside the IIS worker process
  • Windows services intended to run continuously in the background
  • Custom COM or ActiveX objects that must be registered with regsvr32 or similar tools
  • Third-party software, libraries, or components requiring server-wide installation or elevated privileges
  • Any application or script needing direct access to modify the Windows registry or system paths

#Common Scenarios and Pitfalls

Many .NET developers encounter these limits when porting legacy code that depends on older COM libraries for tasks such as document conversion, encryption, or integration with line-of-business systems. Background processors implemented as Windows services for queue management or scheduled jobs will not start. A frequent mistake is uploading a custom DLL and expecting it to register automatically; without administrative rights the registration step fails silently or throws runtime exceptions. Another pitfall involves NuGet packages that wrap native components needing installation steps beyond simple bin deployment. Testing locally on a full administrator workstation gives a false sense of compatibility that collapses when deployed to shared hosting. Review dependencies early using tools like Dependency Walker for native DLLs or Fusion Log Viewer for .NET assembly issues.

csharp 
// C# example attempting to instantiate a COM object.
// This will fail at runtime on shared hosting if the component is not pre-registered.
using System;
using MyLegacyComLib;  // Reference to COM interop assembly

public class ComExample {
    public void RunProcess() {
        try {
            MyComClass comObj = new MyComClass();
            comObj.PerformOperation("input data");
        } catch (Exception ex) {
            // Typical error: "Class not registered" or "Access denied"
            Console.WriteLine("COM failure: " + ex.Message);
        }
    }
}

#When to Move to VPS or Dedicated Servers

VPS and Dedicated server offerings remove these barriers by providing administrative access and isolated resources. You can install arbitrary software, register COM libraries, create and start Windows services, deploy custom executables, and tune IIS or the operating system as needed. This is essential for applications with strict dependency chains, real-time processing requirements, or specialized security configurations. The transition is straightforward once you identify that shared hosting cannot support the required components. Perform an audit of your solution's architecture, listing every external DLL, service, and installer prerequisite. If any item matches the prohibited list above, select a VPS or Dedicated plan from the outset to avoid downtime and data migration overhead later.

Assess your application's technical requirements against these hosting policies before purchase. Starting on the correct tier prevents refactoring, emergency upgrades, and lost development time. The core policy on shared hosting exists to protect all customers; respecting it leads to reliable operation within its boundaries or a smooth move to more capable infrastructure when custom execution is mandatory.