Should developers keep the web.config file updated and commit it to a VCS such as SVN? At my company we very rarely update it via SVN; instead somebody will create an "instructions" text file in our deployment scripts (SQL scripts and the like, plus batch files to compile the ASPX files as individual DLLs for deployment) that says something like "Change X to Y in web.config files for Sites A, B and D", and relies on the individual developer following those instructions each time the file is updated.
This seems counter-intuitive to me: I would expect the web.config file to be kept in sync as needed, with necessary changes being made and the file committed as any other artifact of the codebase, but I have raised this issue in the past and nobody has paid it any mind.
What approach should be followed when dealing with config files like this?
Absolutely, web config must be in source control, and you can define differences beetween various versions of web.config with web.config configurations
for example we have one for local development server, one for test IIS server, and one for production IIS server. And we can set solution configuration and publish from visual studio for different targets and different clients (sites).
here are the links for web.config configurations :
Common Web.Config transformations with Visual Studio 2010
Web.config Transformation Syntax for Web Application Project Deployment
I wouldn't allow all developers to have access to web.config file at all either via SVN or other way. Although if in your company it is allowed for developers to access web.config i see no reason why it shouldn't be on SVN. Point of SVN is to keep track of your single/multi person development process. If you make changes to web.config and this cause a bug in someone's else code it would be much easier to revert changes using SVN
Related
I was exploring options for deploying my ASP.NET web app by creating a publish profile when I noticed that .pubxml files are included in this .gitignore file (which I had been using):
https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
Searching around, the reasoning seems to be that either references to the publish profile or references in the publish profile contain absolute paths or other information that may only be valid on the local dev machine at the time.
Can anyone confirm the reasoning behind this exclusion?
I cannot confirm the reasoning but I can tell you what we do. I include the .pubxml files in source control due to the fact that any of us can publish to our DEV or TEST environments. I even checked the files themselves and did not see any local paths. But consider that we use web deploy, so long as we all have access to the same server to deploy to, then there is no problem.
So it really, IMO, depends on what deployment settings you use and if all of your team have access to the same servers.
No credentials and no local paths are stored in our .pubxml files.
From Microsoft documentation (for ASP.NET Core 2.2 and up)-
When publishing to an Azure target, the .pubxml file contains your
Azure subscription identifier. With that target type, adding this file
to source control is discouraged. When publishing to a non-Azure
target, it's safe to check in the .pubxml file.
Sensitive information (like the publish password) is encrypted on a
per user/machine level. It's stored in the
.pubxml.user file. Because
this file can store sensitive information, it shouldn't be checked
into source control.
This is correct. These publish profile files have local settings like target path to deploy which may be different for different systems. So it is always kept these files only locally.
Can I safely delete the contents of this folder
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root
on a Windows 2003 R2 standard system, given that I am not using IIS (6/7) on it?
If that is the case, could you please point me to the relevant documentation about ASP.NET's runtime and maintenance tasks such as this?
Yes, it's safe to delete these, although it may force a dynamic recompilation of any .NET applications you run on the server.
For background, see the Understanding ASP.NET dynamic compilation article on MSDN.
Just an update on more current OS's (Vista, Win7, etc.) - the temp file path has changed may be different based on several variables. The items below are not definitive, however, they are a few I have encountered:
"temp" environment variable setting - then it would be:
%temp%\Temporary ASP.NET Files
Permissions and what application/process (VS, IIS, IIS Express) is running the .Net compiler. Accessing the C:\WINDOWS\Microsoft.NET\Framework folders requires elevated permissions and if you are not developing under an account with sufficient permissions then this folder might be used:
c:\Users\[youruserid]\AppData\Local\Temp\Temporary ASP.NET Files
There are also cases where the temp folder can be set via config for a machine or site specific using this:
<compilation tempDirectory="d:\MyTempPlace" />
I even have a funky setup at work where we don't run Admin by default, plus the IT guys have login scripts that set %temp% and I get temp files in 3 different locations depending on what is compiling things! And I'm still not certain about how these paths get picked....sigh.
Still, dthrasher is correct, you can just delete these and VS and IIS will just recompile them as needed.
I just upgraded to Visual Studio 2010 and MVC 2.0 and I noticed the Web.config has two additional files attached to it? Are these files used to specify debug and release specific settings, so you don't clutter up the main Web.config?
Does it even make sense to place a connection string in the root Web.config file if I have a local and remote one in the debug and release Web.configs respectively?
Thanks!
It's the new Web.config transformation feature of Visual Studio 2010. More information here.
Edit:
Are these files used to specify debug and release specific settings, so you don't clutter up the main web.config?
It isn't limited to three files, you could (in theory) have as many files as you have environments. The "top level" Web.config provides a template of your web config. The files under it provide replacement values specific to that environment (like if you have different connection strings for local/stage/test/whatever).
Does it even make sense to place a connection string in the root web.config file if I have have a local and remote one in the debug and release web.configs respectively.
It would only make sense if it wasn't going to change between environments. Sounds like in your case it does so, in your case no, it would not make sense to leave it in the Web.config.
These are Web.config transformations files. From ASP.NET Web Deployment using Visual Studio: Web.config File Transformations:
There are two ways to automate the process of changing Web.config file settings: Web.config transformations and Web Deploy parameters. A Web.config transformation file contains XML markup that specifies how to change the Web.config file when it is deployed.
You can specify
different changes for specific build configurations and for specific
publish profiles. The default build configurations are Debug and
Release, and you can create custom build configurations. A publish
profile typically corresponds to a destination environment.
In case anyone is interested, here is something I wrote up to have a dynamic connection string per environment. I wanted to deploy the code to any environment (Dev, Test, Pre-Prod, Prod...) without having to worry about changing connection strings. I couldn't really find a good way to do this with Asp.Net MVC 4, so I came up with my own way to rely on a properties file per environment.
There may be a better solution, I come from a Wicket/Java background and recently started developing with MVC 4 so, it's possible a better solution exists. But here is a link to my question and answer for a dynamic connection string:
Asp.net MVC 4 dynamic connection string
That was something long needed in VS. Unfortunately there seems to be a problem with the implementation. For example consider this scenario (VS.2010 Ultimate, all SP):
Web.Config
No connectionStrings section
Full Membership User/Role/etc. Provider configuration using connectionStringName="test"
Web.Release.Config
No membership configuration (already specified in main web.config)
connectionStrings section including the CS named "test"
Web.Debug.Config
No membership configuration (already specified in main web.config)
connectionStrings section including the CS named "test"
When executing the application gives the following error:
The connection name 'test' was not found in the applications configuration or the connection string is empty.
In other words, because the connection string elements are in the Release/Debug designer files and used by configuration elements in the main (Web.config) file, it is unable to resolve it.
I'm using a Web Deployment Project in Visual Studio 2008 in order to prepare my ASP.NET application (ASP.NET web application, not ASP.NET web site) for being copied to several servers. I have to copy the files on local staging servers, on different servers via FTP and sometimes I have to fetch them from customers' servers.
So, it would be nice to have all files for deployment in a compact form without the necessity of doing a lot of comparing between source and destination. Web deployment projects have this nice feature: compile all your aspx and ascx files into a single (additional) assembly.
I somehow found out how to get rid of aspx placeholder files on the server, now I'd like to know if there is a (maybe self-made) way to get rid of these .compiled files.
From Rick Strahl's blog:
The .Compiled file is a marker file
for each page and control in the Web
site and identifies the class used
inside of the assembly. These files
are not optional as they map the ASPX
pages to the appropriate precompiled
classes in the precompiled assemblies.
If you remove the .Compiled file, the
page that it maps will not be able to
execute and you get a nasty execution
error.
Anybody out there with a creative idea, maybe using a module/handler which intercepts the check against the .compiled files in the bin folder?
The .compile file comes from pre-compiling on deployment. So you basically have 3 options:
Keep the .compiled file
Don't pre-compile and deploy source code
Turn this in to a Web Application instead of a Web Site and compile as an assembly
I have run in to the same problem myself. I actually choose #1 in most cases when dealing with deployment of Web Sites, but on the rare occasion when I know I am going to have to maintain the site for an extended period of time, I take the time to upgrade it to a Web Application.
I don't like the .compiled files either, but nobody gets hurt if they're there. So why bother?
You might want to take a look at Virtual Path Providers (KB how to here) in ASP.NET.
Credit for this suggestion must go to Cheeso and his self answered question here:
Can I get “WAR file” type deployment with ASP.NET?
I don't know about the .compiled files, but you could set up your servers to update their files with subversion instead of manually copying the files when you compile.
So you would compile the files using the Web deployment project (not into a single assembly), put them in a repository you created for this purpose, and on each server, just do an svn update to fetch and compare the files automatically.
I know it's not what you asked for directly, but it may be a path to explore.
Add "Exclude Filter" to your deployment project:
In the Deployment Project.
Right Click on Content Files.
Click on "Exclude Filter".
Add "*.Compiled"
click OK.
and thats it.
I remember at the days when I cant do Web Application with VWD Express, I use nant script to compile the project into a single dll and deploy, that would work (so I dont need the full VS to do dll deployment too), so if you really don't want to mess your project to Web Application, maybe this is a path to check too.
You can get rid of the .compiled files by using the aspnet_merge tool with the -r option.
Removes the .compiled files for the main code assembly (code in the App_Code folder). Do not use this option if your application contains an explicit type reference to the main code assembly.
If you publish your code as updateable (in publish settings) these files are generated. Uncheck that value and republish. This is an old question I know, but no answers are clearly defined for this here.
Is there a security risk associated with using the option that copies "All project files" when publishing a web application into a production environment? I normally use the option "Only files needed to run this application" which does not copy the source code to the server.
I am the only person with access to the production server. There is also no issue with cluttering the production server as there isn't much on it. In fact I don't mind having all the source files be kept on the server together with the binaries.
Is there any security issue with this?
If no one can get access to the production server then there is no security risk with this option. However this is a pretty big if! I can’t see any real benefit from using the All project files or All files in the source project folder options – these don’t even allow you to update the web application in place on the production server which might be useful in some situations. I would stick to the Only files needed to run this application option just to be save.