Hosting ASP.Net fails after upgrade to .Net 2

[Paul Newman]

I have been hosting ASP.Net in my app for some time, with no problems, with
framework 1.1 (VS 2003). Having just upgraded to 2.0 (VS 2005), and it now
gives this error:

HttpException (0x80004005): The path '/MyApp/App_GlobalResources/' maps to a
directory outside this application, which is not supported.

The ApplicationBase for my app is "/MyApp" so the statement in the error
message would appear to be incorrect. I have no explicit mapping for
"App_GlobalResources". It makes no difference whether the subfolder actually
exists.

Here's the code that creates the host:

public static Host Create(Type HostType, string VirtualDir, string
PhysicalDir, string AppBase, string BinPath)
{
if (!PhysicalDir.EndsWith("\\"))
PhysicalDir += "\\";

string aspDir = HttpRuntime.AspInstallDirectory;
string domainId = "ASPHOST_" +
DateTime.Now.ToString().GetHashCode().ToString("x" );
string appName = (VirtualDir + PhysicalDir).GetHashCode().ToString("x");
AppDomainSetup setup = new AppDomainSetup();
setup.ApplicationName = appName;
setup.ConfigurationFile = "web.config";
setup.ApplicationBase = AppBase!=null ? AppBase : (AppBase = PhysicalDir);
setup.PrivateBinPath = BinPath!=null ? BinPath : AppBase + "bin";
setup.PrivateBinPathProbe = "*"; // if non-blank, excludes AppBase from
search path, so only looks in PrivateBinPath.
setup.DisallowCodeDownload = true;

AppDomain ad = AppDomain.CreateDomain(domainId, null, setup);
ad.SetData(".appDomain", "*");
ad.SetData(".appPath", PhysicalDir);
ad.SetData(".appVPath", VirtualDir);
ad.SetData(".domainId", domainId);

// VS2003 only:
//ad.SetData(".hostingVirtualPath", VirtualDir);
//ad.SetData(".hostingInstallDir", aspDir);

// VS2005 only:
ad.SetData(".appId", appName);
string dataDir = PhysicalDir + "App_Data";
ad.SetData("DataDirectory", dataDir, new
System.Security.Permissions.FileIOPermission(Syste m.Security.Permissions.FileIOPermissionAccess.Path Discovery,
dataDir));

Host host =
(Host)ad.CreateInstanceAndUnwrap(HostType.Module.A ssembly.FullName,
HostType.FullName);
return host;
}

The other way to create a host is to use the ApplicationHost CLR class, as
in the following code, whic does work. It is simpler, but does not allow
control of PrivateBinPath. By the time CreateApplicationHost returns,
assemblies have been loaded in the new AppDomain, so it is too late to set
it. That's why I need to use the above method.

public static Host Create(Type HostType, string VirtualDir, string
PhysicalDir)
{
Host newHost = (Host)ApplicationHost.CreateApplicationHost(HostTy pe,
VirtualDir, PhysicalDir);
return newHost;
}

The line 'ad.SetData("DataDirectory" ...etc.' in the first method makes no
difference, I included it in an attempt to mimic the AppDomain created by
the second method (I saw in the debugger that it added such an entry).
Granting 'AllAccess' instead of 'PathDiscovery' makes no difference either.

Thanks
Paul Newman

[Paul Newman]

"Paul Newman" <pnewman@aurora-solutions_NoSpamPlease.netwrote in message
news:FU******************@newsfe7-win.ntli.net...

>I have been hosting ASP.Net in my app for some time, with no problems, with
framework 1.1 (VS 2003). Having just upgraded to 2.0 (VS 2005), and it now
gives this error:

HttpException (0x80004005): The path '/MyApp/App_GlobalResources/' maps to
a
directory outside this application, which is not supported.

The ApplicationBase for my app is "/MyApp" so the statement in the error
message would appear to be incorrect. I have no explicit mapping for
"App_GlobalResources". It makes no difference whether the subfolder
actually
exists.

Here's the code that creates the host:

public static Host Create(Type HostType, string VirtualDir, string
PhysicalDir, string AppBase, string BinPath)
{
if (!PhysicalDir.EndsWith("\\"))
PhysicalDir += "\\";

string aspDir = HttpRuntime.AspInstallDirectory;
string domainId = "ASPHOST_" +
DateTime.Now.ToString().GetHashCode().ToString("x" );
string appName = (VirtualDir + PhysicalDir).GetHashCode().ToString("x");
AppDomainSetup setup = new AppDomainSetup();
setup.ApplicationName = appName;
setup.ConfigurationFile = "web.config";
setup.ApplicationBase = AppBase!=null ? AppBase : (AppBase =
PhysicalDir);
setup.PrivateBinPath = BinPath!=null ? BinPath : AppBase + "bin";
setup.PrivateBinPathProbe = "*"; // if non-blank, excludes AppBase from
search path, so only looks in PrivateBinPath.
setup.DisallowCodeDownload = true;

AppDomain ad = AppDomain.CreateDomain(domainId, null, setup);
ad.SetData(".appDomain", "*");
ad.SetData(".appPath", PhysicalDir);
ad.SetData(".appVPath", VirtualDir);
ad.SetData(".domainId", domainId);

// VS2003 only:
//ad.SetData(".hostingVirtualPath", VirtualDir);
//ad.SetData(".hostingInstallDir", aspDir);

// VS2005 only:
ad.SetData(".appId", appName);
string dataDir = PhysicalDir + "App_Data";
ad.SetData("DataDirectory", dataDir, new
System.Security.Permissions.FileIOPermission(Syste m.Security.Permissions.FileIOPermissionAccess.Path Discovery,
dataDir));

Host host =
(Host)ad.CreateInstanceAndUnwrap(HostType.Module.A ssembly.FullName,
HostType.FullName);
return host;
}

The other way to create a host is to use the ApplicationHost CLR class, as
in the following code, whic does work. It is simpler, but does not allow
control of PrivateBinPath. By the time CreateApplicationHost returns,
assemblies have been loaded in the new AppDomain, so it is too late to set
it. That's why I need to use the above method.

public static Host Create(Type HostType, string VirtualDir, string
PhysicalDir)
{
Host newHost = (Host)ApplicationHost.CreateApplicationHost(HostTy pe,
VirtualDir, PhysicalDir);
return newHost;
}

The line 'ad.SetData("DataDirectory" ...etc.' in the first method makes no
difference, I included it in an attempt to mimic the AppDomain created by
the second method (I saw in the debugger that it added such an entry).
Granting 'AllAccess' instead of 'PathDiscovery' makes no difference
either.

Thanks
Paul Newman

Anyone?

It would be good to hear from anyone who HAS managed to host asp.net in
their app, but didn't get this error. At least that would mean the framework
is not at fault.

TIA