Come work for Umbraco - The Umbraco HQ are hiring Project managers, .NET developers and DevOps people!
We're planning to use Umbraco for the next refresh of our website, but have hit a configuration/organization snag. We're using Umbraco 18.104.22.168 and IIS 6.0, asp.net 2.0. We have several pre-existing web apps under the current root website, like www.example.com/oldapp/. Umbraco will have to be installed as the root of this website. We don't have the resources to rebuild all the apps as Umbraco-based apps, so we tried excluding them from Umbraco using umbracoReservedPaths, like so:
<add key="umbracoReservedPaths" value="/umbraco,/install/,/oldapp/" />
We then get a config error when we navigate to www.example.com/oldapp/. This is the error:
not load file or assembly 'UrlRewritingNet.UrlRewriter' or one of its
dependencies. The system cannot find the file specified.
(D:\Inetpub\wwwroot\umbracotest\web.config line 79)
We tried removing the trailing slash from the umbracoReservedPaths key value, putting the old in the same app pool as umbraco, with no difference. The old app's web.config is inheriting from umbraco's web.config. Even when the umbraco app pool is disabled we get the error, so it's like umbraco isn't even kicking in yet. I know about <clear /> elements and <location allowOverride="false"/>, but those seem like hacks in this situation. (And I'd think <location allowOverride="false"/> would break umbraco.) What's going on here?
I would be interested in an answer to this as well, if anyone would be willing to help. I tried to vote up the topic but it looks like I don't have enough karma yet :)
We have several own applications in subfolders of umbraco. Did you mark the folder with the old webapp as web application in IIS? Then it takes the web.config of the subfolder without inheritance of the root folder (I guess so). We added an entry like this to the key:
<add key="umbracoReservedPaths" value="/umbraco/,/install/,/SUBFOLDER_WITH_THE_OTHER_APP/" />
Exactly as Thomas said, any separate applications need to be registered in IIS as virtual folders, otherwise their assemblies won't get loaded.
You could try to put all sub-app .dll's in the main /bin, and all settings in the one web.config, but I don't think that's a very scaleable, or maintainable approach.