views:

118

answers:

2

I want to run my new web application with forms authentication under the ASP.NET Development WebServer (Cassini), but not at site root "/" (rather, at the path it will reside in production; "/New").

However, the build process gives the error:

"It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS. New.MvcWeb\obj\debug\csautoparameterize\original\web.config"

Now, I understand what it is saying. I have forms authentication enabled in my web.config in a virtual directory. The error goes away when I remove the web.config, or remove the "virtual path: /New" debugger configuration, or move debugging from Cassini to IIS and manually create an application at "/New".

But it is only a 'virtual' directory in the mind of the Build System. The path IS application-enabled in a production IIS setting. Also, if I remove the web.config, Cassini will happily publish "http://localhost/New" as an application (for example, Server.MapPath("~") returns my project directory without the "/New" suffix); however I need forms authentication (an application-level web.config parameter) enabled in it.

How I can avoid this build error while retaining my desired features?

More Details

The project is currently configured for "file-system" site development. This and Cassini are supposed to make it easier for my content creators to participate in development and testing with their local copy of VS2010, without having to install IIS on their Windows PCs. I will also one-click publish to my local IIS for testing, then package/publish/deploy to public test, then finally publish to production. In my mind I imagine Cassini being a very helpful part of this whole process.

VS2010, MVC application, file-system site project

Project Settings:
 * ASP.NET 4.0
 * Use Visual Studio Development Server  
 * Virtual Path: /New

web.config snippet:
 <authentication mode="Forms">
   <forms loginUrl="~/../login.html" timeout="30"/>
 </authentication>
+1  A: 

I'd generally argue apps should never care if they are running as the root or in a sub-uri. I'd also say that, in 2010, with IIS Express coming, it makes no sense investing any time nor heartache in fighting cassini. That should support your requirements much better.

EDIT FOR MORE DETAILS

Interesting updates about IIS express. We do some of the same things for our design types -- we'd rather they implement the designs rather than the programmers lose hours of their life pursuing individual pixels. We found it easiest to basically treat the designers' machines as essentially continuous integration build agent. They run IIS and build using the same command line build script the CI boxes do. Works surprisingly well. In both cases you have a machine that can't care for itself, so everything needs to be scripted. The IIS bit gets setup once generally as we keep it pretty simple and it rarely needs tweakage with modern versions of .NET. Hope this helps.

Wyatt Barnett
Thank you Wyatt. I agree, the app itself shouldn't care if it is at root or "/New". But it has links from the original, non-MVC site that IS at the root, and the out-of-site links care very much what the relative path is. We can't flash migrate the whole site to MVC. I (more importantly my contributors) need to run the two sites side-by-side for testing, demo, and production.
Shannon
Gotcha, that makes a whole lotta sense. Got more than a few apps that behave that way, we typically make them fly on IIS as if you are doing demos, you shouldn't need the VS development environment.
Wyatt Barnett
Thank you Wyatt for the reference to IIS Express. I totally agree, it forecasts solving these relevant problems I have today - understanding how to configure/manage IIS on content-creator workstations, requiring administrator privileges to launch Visual Studio projects, company IS staff disallowing IIS, etc.Too bad IIS Express is part of WebMatrix, is in beta, won't be available until "later in the year", and won't be integrated to VS debugging until the following major VS SP release.
Shannon
PS your info got me to here, which is where I got the sad forecast on IIS Express. http://channel9.msdn.com/blogs/glucose/hanselminutes-on-9-razor-iis-express-sql-4-compact-edition-and-vs2010-tooling-with-damien-edwards
Shannon
Yeah, thanks Wyatt for the update. I'm probably going to have to resort to putting IIS on designer's boxes and get them admin logins, both of which will require additional system admin blessings. I'll also have to figure out how to get that IIS maintenance happening, which you mention coming from scripts. Unfortunately, we're a small shop, so any magic like that has to come from me. Which brings me back to wishing the MS product worked the way I (and probably others) want out of the box...
Shannon
Also, I don't see this defect will necessarily be resolved by IIS Express (or "WebMatrix"). It seems the root of the problem is really that the subdirectory IS an application to Cassini, but the build process still raises errors on the web.config as though it isn't. Hackishly, this doesn't occur in IIS if the developer has manually set that directory to an application - the configuration of IIS publish point shouldn't relate to the build process. Even though my project (and even the package and deployment) settings can flag the project as an app, the build process doesn't respect those flags.
Shannon
A: 

So, having learned that Cassini actually does run paths as applications [i.e. Server.MapPath("~") returns the project root folder, and Server.MapPath("/") may not exist], it really becomes strictly a build error.

With a better problem definition, I now see other people also have this error in MVC projects with MvcBuildViews and One-Click-Publish. Here are some articles on how to avoid it:

http://stackoverflow.com/questions/2566215/allowdefinitionmachinetoapplication-error-when-publishing-from-vs2010-but-onl

http://connect.microsoft.com/VisualStudio/feedback/details/556312/mvcbuildviews-does-not-play-well-with-one-click-publish

Shannon
I've verified that I can hack the problem by cleaning the solution (after packaging but before the next build). It was confusing at first because I was trying to clean while I had the package folder in-use by another process. Of course, it's still a VS defect, but I've got a lock on root cause now and the defect is acknowledged so I'm happy...
Shannon
My mistake, I often have to manually clear files from the obj folder, cleaning does not clean the packageTmp.
Shannon
It's the:{$Project}\obj\{$Config}\CSAutoParameterizedirectory that has to be removed
Shannon