I'm trying to develop my first web application using Web.Config transformations.
Trying to run the app (building with the "Dev" build configuration)in the Asp.Net Debugging web server built into VS the site doesn't seem to work - the "Web.Dev.config" configuration doesn't appear to be seen by the application.
Is this to be expected? Is it only when deploying that the transformations happen?
Many thanks!
In any asp.net web site, only web.config is examined by the web server. web.dev.config will always be ignored (treated as nothing more than an unknown file). This is true regardless of whether running in Visual Studio or IIS.
Related
Trying to migrate a legacy ASP.NET WebForms/MVC hybrid application from Cloud Services to App Services. All runs fine locally in debug Visual Studio (V2022). The app is predominantly webforms but MVC has been retro fitted and is in use for some pages. It's using .NET Framework 4.8.
Deploying directly from Visual Studio. We have created a new App Service and App Service Plan. The site appears to deploy correctly but the endpoint returns the below as raw text, i.e. the web browser doesn't even attempt to render it, presumably as there is no header information specifying html content-type:
Have checked the configuration for the app service, all appears normal (same as other app services that run quite normally). It's set to ASP.NET 4.8 with all the other standard defaults. The default documents includes Default.aspx which matches the application. The application is using Forms authentication and defaults to a Login.aspx page. We have tried removing this and redeploying but we still get the same result. Configuration and Management diagnostics section on the Azure portal shows no significant errors.
In Kudu (advanced settings) if I access the debug console, I find my app is deployed to c:\home\site\wwwroot> as expected, however if I click "Site Root" it flips me to c:\local>
Could it be IIS is pointing to the wrong path for the site?
In the end found some rogue code that was causing the issue. The different paths under Kudo was a red herring.
To diagnose the problem we moved from VS deployment to CI deployment and still had same issue. This meant it was not publishing settings. We compared web config with other solutions that ran fine as app services and found no significant differences. This ruled out IIS settings from web.server section. We checked for errors on the app and found no errors being reported.
In the end we trawled through the code and eventually found something that was URL specific.
This is not as straight forward as I had hoped.
I created a Web Site project on my development machine using the Visual Studio C# template for a WebSite Project. (Visual studio 2010 .net 4.0). The project name is C:\Nova5\WebSite3. It consists solely of:
the Bin subdirectory
Nova.svc file
web.config file
It has been tested to run correctly by:
Setting the website as the startup project, then
Run Debug-->Start Debugging
When tested, the NovaDataService information page is correctly displayed. It also correctly works when used through my client project.
I followed the recommended procedure described at
Walkthrough: Converting a Web Site Project to a Web Application Project in Visual Studio to covert the Web Site to a Web Application.
I now have the following problems and/or difficulties:
If I use the recommended procedure for testing the web site:
-- File | Open | Web Site
-- Build Web Site -- Start Debugging
I get the Error: The type 'Nova5WCFServiceLibrary.NovaDataService', provided as the Service attribute value in the ServiceHost directive, or provided in
the configuration element system.serviceModel/serviceHostingEnvironment/serviceActivations could not be found.
Since, I think, the WebSite does work, I skipped this error and moved on to the next part of the article. The next issue (?) is there is no App_Code file in the WebSite. Is this necessary? If it is necessary, how should I create it? Or do I need to create another WebSite project from its template just to have it?
I did not copy the Nova.svc nor the web.config from the WebSite to the Web Application as none of the references I read indicated to do so. Should I copy these files to the Web Application as well?
I now used the "Convert to Web Application" on the Web Application project and recompiled the solution. Everybody is happy. No errors reported. So how do I now test the Web Application project on my development machine (which also has the client application) ?
TIA
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>
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.
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:
allowDefinition='MachineToApplication' error when publishing from VS2010 (but only after a previous build)
http://connect.microsoft.com/VisualStudio/feedback/details/556312/mvcbuildviews-does-not-play-well-with-one-click-publish
I have a web application that I'm trying to create a Web Deployment Project for in Visual Studio 2008. My application also has a child web application. Both are web applications in IIS. I have added the Web Deployment Project so that I can automate the build process for this application. When I try to build the Web Deployment Project, I get the following error:
Error 639 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.
It's the child web.config that the error is referring to. I've tried to find a solution on the web and while this seems to be a common error, neither of the two suggested solutions seems to fix my problem. The first solution is to make sure the application is an application in IIS which both of mine are. The second is to make sure there are no child web.configs anywhere in the solution. I have a child config but it is part of the child web application and cannot be eliminated.
Is there a way to get the Web Deployment Project to build with an application structure like this? If not, is there a way to automate building .Net web applications using MSBuild without a Web Deployment Project?
Found the answer here Specifically, if you have nested web applications, you need to enable the "Use IIS metabase path for source input" option in the Compliation section of the Web Deployment Project Properties. That will cause only the root application to be built. The default is for the Web Deployment Project to build all applications including children.
Hi guys,
We have a mixed development environment of three servers running: Win Server 2003 & 2008, IIS 7 & IIS 6, ASP.NET 2.0 & ASP.NET 3.5. Previously, all three servers were Server 03/IIS6/ASP.NET 2.0, but with this new change, I am finding that pushing/moving any applications from server to server is always a terrifying experience because there are always a variety of problems with the web.config from server to server. I used to consider myself a confident ASP.NET developer but now I am frightened to come to work every day.
I have always used the web.configs that VS generates for me on the Win 2003/ ASP.NET 2.0 server. None of our web.configs are "leet", they are just normal, although we do use ScriptManager and UpdatePanel.
To get by, as a temporary fix, I'm having to remember that when projects are moved/tested/deployed, never to move or overwrite any web.configs and things get confusing very fast. I've tried "ducttaping" like suggested here my web.configs with the new IIS7 stuff but even that doesn't work all the time.
What can I do here, what's going on? Is there a standard web.config that will work on all of the servers and do the UpdatePanel and ScriptManager ?
[edited question]
Since IIS6 is the baseline install for your application, you should make sure to run the application in "Classic" mode under IIS7. This makes configuration the same as an IIS6 box. This is how we run our web applications for now until we have fully migrated to 100% IIS7 server environments and we have zero problems with deployment/runtime.
To do this you can either choose to run your app under the built in "Classic .NET AppPool" that comes with IIS7 or, assuming you create your own custom application pools, just make sure you set the "Managed Pipeline Mode" to "Classic" under the "Advanced Settings" dialog for the app pool.
You should seriously look at web deployment projects for visual studio 2008.
This is an official add-on for Visual Studio that gives you a new project type called web deployment project. Among the most useful features is the ability to do web.config search/replace as well as pre-compiled builds of your web sites or web application projects.
In your case, what you'd do is create a solution configuration in visual studio for all of your target web servers. Then you'd create a web deployment project for your web app. In the properties for the deployment project you tell it how you want to compile the project and what web.config replacements you want to use for each solution configuration.
The end result should be that you can open Visual Studio, pick a solution configuration, build the deployment project. The build will create a folder with everything you need for that environment including the correctly configured web.config files. Then you just copy the folder to your server and you are up-and-running.
Best of all, since the different config files are all stored in the projecct, it lets you manage your configuration in one place and check it all into source control.
Do note that there is no equivalent in Visual Studio 2010. Instead, VS 2010 has a whole new deployment mechanism called MSDeploy. With 2010 you don't need a seperate project for deployments, and MSDeploy goes a lot further allowing you to package your SQL databases and other stuff too.
You can use the Classic mode under IIS6 by changing the process. That is actually pretty simple and it should work.
Another approach would be to automating your deployment process and have it so that it deploys the correct web.config to the server when you need to update your application.
If you run your IIS 7 websites using the Classic .NET App Pool, then the config files will match what you would use for IIS 6. That's probably the easiest thing to do until you're ready to migrate everything to IIS 7.
Knowledge is a great way to get over fear. Figure out what's going on (you're currently grasping at straws) and the fear will go away.
It's my guess that you'll do better if you refactor the code that uses the config file. Sloppiness there can definitely explain your weirdness and inconsistencies. You can't control much with your config settings if the code isn't behaving properly.