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.
Related
I'm new to .NET core. We're currently implementing an Umbraco9 site which is running on .NET core 5 (MVC). Normally when setting up a development environment on a regular .NET site, I would create the project, point IIS to that same folder, and create a host entry for something like "local.mysite.com" I would then just be able to load up that URL in my browser and the site would serve, simply building when changes to back-end code were needed.
With .NET core, there are obviously some significant differences. For starters, there is a new wwwroot folder inside the project. So, in this case, I've tried pointing my IIS site to that wwwroot folder. This then has the impact of requiring a visual studio publish to that folder for any change front-end or back-end. Furthermore, it seems as though .NET core compiles the cshtml files into a Views.dll file, but when I publish the site, the site throws a 500 unless I manually copy the cshtml files to the wwwroot folder (which also has its own wwwroot after publish).
I've done loads of research on what the generally accepted best practices are with developing and hosting .NET core, but haven't come to a conclusion on this. Further complicating this is that I've seen some information saying that you can use Kestrel in conjunction with IIS. So now it's a matter of Kestrel vs. IISEx vs IIS. I'd prefer IIS as I'd like it to match production.
I've tried setting my IIS path to the path of the VS project, but I get "web server is not configured to list the contents of this directory." I enabled directory browsing, but this of course just lists the files in the directory. I've installed the hosting bundle as well.
The question: Is there a set of generally accepted practices on how to setup local development environments for .NET core projects? I'm really looking for some guidance on .NET core from a non .NET core developer's perspective. I'm trying to make this question as focused as possible, but I feel like there's a gap in my understanding of "old .NET" vs. .NET core and I'm hoping to get some guidance to help fill in that gap.
I wasn't able to get this figured out, so only solution I can come up with is to point IIS at a separate publish folder and publish to that folder when I need to make changes.
On my Windows XP desktop, I have a fairly simple ASP.NET targetting .net 4 in Visual Studio 2010. I can run it on my local host by ctrl + F5, it works all fine.
I have a Windows Server 2003, that I can access via mstsc, but also via Explorer. When I go to the publish section of my build properties, i see 4 publish methods :
Web Deploy, FTP, File System, FPSE
I have already installed IIS 6 successfully on the Windows Server, and given all authorizations for everything I could so far (to get things to work in the first place, will check on that later).
How should I proceed to publish to that remote machine ? Should I target a specific folder ? Do I need to setup things in IIS 6 for that site first ? Or will it all get settled from te properties I have in Visual Studio ?
Thank you guys,
J.
Personally I've always plumped for a manual deployment; that is I create the Web Site in IIS creating an appropriate AppPool and targeting the correct .NET version to utilise. From there simply copy (xcopy if you will) the appropriate files over, e.g. DLL and all supporting pages such as ASPX, CSS and associated images. In most situations where I have direct / RDP access this is what I run with.
That said, this can be automated from Visual Studio and this can be useful for those situations where you're maintaining an awful lot of sites on a regular basis. With IIS 6 and Visual Studio, this was achieved by installing FrontPage Extensions on the server then utilising the Publish option.
For VS2010 it seems this has been streamlined using the IIS Web Deploy module and configuring the Studio to publish in this manner that looks mildly quick...
HTH
I've never used the Web Deploy feature in 2010, so I can't really tell you about its merits or drawbacks. I've read that it works much better with IIS7 than IIS6. If you have direct access to the IIS root folder on the server (typically c:\inetpub\wwwroot) through a network share I would recommend doing the file system deployment. FPSE works as well if you have to publish to the server through a remote URL, but there are some security issues with FPSE that make enabling it on your web server a less than ideal choice.
Once the files have been deployed, all that should be left is to configure the website as an application inside of IIS.
Remote in to the web server and open IIS
Right-click Default Web Site and choose properties (if you've deployed to a subfolder in the root, then locate that folder and choose those properties instead
Switch to the Home Directory tab (Just 'Directory' for a subfolder)
Look for the Application Settings section and click the button that says Create
Optional: Select an app pool if you have created a custom one from the default
That should enable IIS to execute your .aspx files inside of your application. Once you've successfully configured the app for the first time, you can just keep publishing your app to the same location over and over without having to reconfigure it.
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'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.
Currently our dev team set up all the websites they're working on in IIS on their local machine. We're thinking of switching to using the built in ASP.NET development server instead.
Is this a good idea? What are the pros / cons of using the ASP.NET dev Server? Are there any gotchas we should be aware of?
Thanks.
NB: Running on Win XP / IIS 5 / VS2005
Edit:
Didn't realise it was called Cassini.. More answers for Cassini v IIS here.
There is nothing that the ASP.NET Dev WebService can do that IIS can't (You can set breakpoints etc, just attach the VS debugger to the ASP.NET runtime).
However, the ASP.NET Dev WebService does not represent a true production environment, and as such you can get caught by gotchas that you wouldn't expect when you deploy to production.
Because of that, I mandate that all development is done using IIS on a local machine. It doesn't take much work to configure a site in IIS.
It's a very good idea. Here are some reasons for:
You no longer need admin access to your machine for web development (it can still be helpful).
It's much easier to test a quick change and continue work, and faster iteration cycles are good.
It can simplify setup and deployment of your development environments.
The XP version of IIS has limitation that are not present in the Server version that Cassini side-steps.
The only argument I know against is that there are a couple very rare edge cases where the Cassini built-in server doesn't exactly mimic IIS because you're using odd port numbers. I doubt you'll ever run into them, and using Cassini as the primary dev environment does not preclude developers from also having access to IIS on the machine. In fact, my preferred setup is Cassini first for most small work, then deploy to my local IIS for more in-depth testing before moving code back to the shared source repository.
[Edit]
Forgot about url re-writing. You do need IIS for that. And an example of a limitation of the built-in XP IIS is that you are limited to one site in XP (can have multiple applications, but that's a different thing).
I had to switch (back) to IIS for one project, because I needed to set some virtual directories which is not possible on the ASP.NET Development Web Server.
As I stated here: https://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis your developers need to be aware that Cassini runs as the local user, which is typically an admin account for developers. The development will be able to access any file or resource that their account can, which is quite different from what they will see on an IIS 6 server.
The other thing that's a pretty big gotcha is debugging web services is much easier using IIS and vdirs rather than separate Cassini instances.
I know at one point I had an issue with Authentication not working as expected on Cassini (built in development server)
Also, if you need to test things like ISAPI plugins (a re-writer for example) I'm not sure how that's done on Cassini.
The constantly changing port is also rather disconcerting to me. Also, for each web project in your solution it fires up another instance of a Casini server, and each one takes anywhere from 20 to 50 MB of memory.
I use IIS all the time, it's pretty easy to setup, and you guys are already doing that...
I've used both methods and I prefer having IIS locally vs. using the built-in server. At very least you're more consistent with the final deployment setup.
Also, when using IIS 5.1, be sure to get JetStat IIS Admin, it adds functionality that is disabled out of the box on IIS 5, such as being able to setup multiple sites.
I have run into the following limitations with the asp.net dev server:
does not support virtual dirs. If you need them in your app, IIS seems to be your only choice
Classic asp pages dont run in dev server. So if you have a mixed web app (like I have at my client right now), IIS seems to be the solution
If you need an admin UI to configure settings, IIS works better
Of course IIS requires that you be a local admin.
Another distinction I noticed is that Cassini runs as a 32-bit process and you have no control over it, whereas you can control the application pool of your IIS app to disallow 32-bit (assuming your IIS is running on a 64-bit server). This becomes especially important if your web application is going to call APIs in 64-bit processes such as SharePoint Foundation/Server 2010. When you debug your web app with Cassini as your debug server, you'll get "The Web application at url could not be found. Verify that you have typed the URL correctly" type errors when instantiating objects. If you debug using IIS with the app running in an app pool that runs as 64-bit with an identity that allows access to sharepoint database then you'll be able to debug properly.
In VS12 the development server is way slow, takes a few seconds to download a 2kbyte file. This did not happen in vs10. When you have a bunch of jquery files and css this is a real problem. Also every page requeries all the css/js files. Very very slow regression testing.
The main issue I've run into with the dev server is SerializationExceptions with custom security principals stored on the thread context. Details here.