Visual Studio 2015 has moved the IIS Express configuration file from My Documents into its own hidden .vs directory and tells IISExpress.exe to use that configuration file.
While this may sound like a good idea when you have multiple web applications with conflicting configurations, in fact it's not when you have web applications with custom configurations at all. Because this config file is in a temporary directory which can be deleted when checking out code into a new location from source control, or when cleaning up things in general.
The old location in the Documents folder is a central location and files there usually won't be deleted. If I need to make some changes to this file, like allowing the application to use Windows authentication, I edit this file once and I'm done. Now with the new location, I may need to make these changes multiple times. And since there's two config files (the old location still exists for me), it's even more confusing.
Then you shouldn't commit anything from .vs into version control, so it's not even possible to share these customisations with other team members.
What is the recommended way to update the applicationhost.config file so that it provides the environment required by the web application? Is there a tool that can run in a pre/post build step? Is there a customisation XML file that can be merged into the default file from .vs?
Is it possible at all to just check out a web application from source control and let it work in a local IIS Express? Or will it always require manual corrections after getting the code and web.config?
PS: I've forgotten one thing: There's the <UseGlobalApplicationHostFile> element in the project file which can be set to true, but as soon as I do that, I get an access denied error message every time I want to start the web application. So that doesn't seem to work well.
Related
I have an ASP.NET Core project that I'm developing and I'm making use of LiteDB as a database solution. In order to instantiate my database I need to provide a URI so that the program knows where to create the database.
Usually I'd do something like System.Environment.CurrentDirectory() to find the current directory I'm in and modify that, however the result of this command turns out to be C:\program files\IIS Express or something similar. Basically the current directory points to the location of IIS Express.
Instead I want to get the root of my ASP.NET project, the location that contains my controllers folder, appsettings.json, bin and obj folders.
What command do I need to use to get a string representing this location? I don't want to use a hard coded string for obvious reasons.
If you don't have access to DI you could try:
Assembly.GetExecutingAssembly().Location
If you have access to DI, try this:
Inject the IHostingEnvironment and call environment.ContentRootPath
How to get root directory of project in asp.net core. Directory.GetCurrentDirectory() doesn't seem to work correctly on a mac
You may be better served by using a dedicated location (such as a network share) rather than the folder that contains the executable code. Having user data mixed into deployed code comes with a lot of headaches:
Deployments become more complex as they need to account for the presence of user data. This is especially true if you need to delete pre-existing code during a deployment.
If the user data is sensitive, developers may be denied access to read the deployed code. This can make troubleshooting issues much harder.
Backups of deployed code will contain user data, which means they will always appear to be different even if nothing (code-wise) has changed.
Of course, this all assumes that the production environment is configured differently from developers' local machines.
i want to copy contents, code, build files and configuration files from a IIS(7.0) server which is running a live file and copy everything
to another machine which got IIS 8 installed.
the destination computer has other web sites installed, so i dont want to disturb configuration for those sites.
do i first copy the code from the source and create a folder on destination and copy the files there and than follow with the configuration settings?
Probably meant for serverfault...but here goes..
Review/inventory current application. e.g.
"config files" for any explicit settings that may have to do with paths, connections (db), certificates (ssl), and/or expected depedencies (assemblies, framework version/s, other web applications, etc.)
hopefully the application is documented and/or original developers are handy to assist in this inventory process
the point is to first "know" what you're moving before doing anything, this would be the most important step..the rest is more or less config....
create folder in target machine
doesn't have to be in C:\inetpub\wwwroot, but you'll have to modify permissions as necessary.
also if there's an existing app in wwwroot, possible headaches can arise with settings inheritance
copy files from source -> target
IIS Manager -> set up the new "web site"/"Application" as necessary (AppPool, etc.)
Test, test, test
Fallback plan (if all goes to hell, need to "revert")
Applicable network stuff - DNS, etc. (the moment of truth)
Coffee. Lots. Pray you don't have to go to #6 :)
Hth...
We are working on a ASP.NET MVC site. I am a dev who is also responsible for prod deployments with other members of the team distributed across the globe.
Today I started working on the web.release.config transformation file for production deployment, and it made me thinking that I really don't want other devs to have access to these files since they contain sensitive production information. But, in VS 2010 these files are placed right next to the dev web.config, so if I check them in, then, the rest of the crew will see them.
Is there a recommended way to use VS2010 to apply transformations to web.config files in such a way that these transformation files don't have to be located with the rest of dev files? Or, do I need to use some kind of automated build tools such as NANT or MS Team Server to do that?
Thanks for your advice.
I typically use the src= tag on the web.config connection file to have a separate file for connection strings for production server that the developers don't have access to to keep it secure. Then in my build process, I grab the webProd.config file from a more secure place and update the server with it.
Q:
I want to ask if publishing the .cs and the .aspx files on my server during web application publishing process considered as a bad practice and may cause security violation or not?
because sometimes i have to do this because the report files doesn't published or the css files doesn't work properly .
When to use each option of those:
Only files needed to run this application.
All project files.
All files in the source project folder
This may be a misapplication of the principle, but I always think of the principle of least privilege. By that, I mean:
Do my users need to see any code files (applicable under both "All project files and "All files in the source project folder"?
Do my users need to see any files in my project folder, but not included in my project (applicable under "All files in the source project folder")?
If the answer to those questions is no, then I publish using only files needed to run this application.
I once made the mistake of publishing a website using "All files in the source project folder", because I needed to deploy a bunch of .css and .js files from a plug-in I used, and didn't know how to quickly include those files in my web project.
However, as soon as I saw all my source code show up in my production folder, I quickly switched my publish option back to "Only files needed to run this application", and deployed deleting all files in the target folder. Then, I looked around to find a way to include all files in a folder that was not in my project, and I've been happier since.
Honestly, even if my users needed to see code of some sort, I'd consider writing a quine before I'd publish copies of my .cs file on any website. People have differing opinions about Internet security, but I often think of this quote from Gene Spafford:
The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.
If you look around here, you'll find various questions where users are trying to safely encrypt/decrypt connection strings, store data securely in their programs (or databases), and are otherwise trying their best to keep anyone -- even their most trusted users -- from getting access they otherwise shouldn't have.
As unlikely as it might be that a malicious user would try to access the files on your server, I can tell you that it's a lot harder for a malicious user to access the files on my server, because those files don't exist on my server.
Ensure your IIS settings mean that .cs files are not served publicly. This should be the same with any sensitive or non-public filetypes, such as .config.
.aspx files contain your markup, so are typically fine to publish and serve publicly.
I have a team of three developers, two of whom use a standard local test database, one of whom uses his own database and there is also a server environment with a production database and a testing database.
This amounts to multiple connection strings required.
The web.config file periodically gets updated and keeps having to be changed by each developer when a source control update is performed, as well as the fact that sometimes a developer accidentally checks in his personal web.config file change with his connection string, which temporarily interrupts us after running a subsequent update from source control.
What can I change so that the web.config file can be committed/updated as often as is necessary and not result in broken connection strings for other developers or require modifications before it can be uploaded to the testing or production environments?
You might want to look at replacing the ConnectionStrings section of the Web.Config with a Config Source file, commit the LIVE set of connection strings into source control, but not include them in the actual solution.
Information on using the configSource attribute can be found in the section "Using External Configuration Files" in the document:
Connection Strings and Configuration Files
This has the advantage that developers could have their own settings that don't get checked into the main Web.Config. The potential downside is that it's yet another file that you have to worry about, and depending on how you're getting the latest version out of source control might not help (i.e. if you go to your SC client and say "Get latest" that would overwrite the file, whereas if you are in Visual Studio, right click on the solution/project and select "Get Latest" that will only get files in the projects).
For the question regarding the testing and production environments, you can make use of the Visual Studio Web Deployment Projects. With that, you can define sections in the web.config that will be replaced when you build the deployment package for the test / prod server.
You could use the Enterprise Library Data Access Block to handle your database connections. You can then define as many connection strings as you want and simply change the use key to whichever one is required. See http://www.devx.com/dotnet/Article/30910 for more information.