I'm quite new to programming. I have an ASP.NET 4.0 application and I would like some guidelines and best practise for how to dev, test and deploy it with regards to environment configuration.
I am currently manually changing my Web.Config file when I've finished a round of development, I then publish it to the web server using Visual Studio.
For example in my Web.Config should I define the connection strings for my dev/test/prod SQL Server databases in there? How should I configure Visual Studio? Are there any good articles on this that you could recommend?
The source code is kept in SVN, which is checked in using Tortoise SVN.
Thanks,
Mark.
I've seen people keep files web.config.dev and web.config.live in the repository and then rename it to web.config when deployed.
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.
i am looking for a way to autodeploy a Dot Net Nuke website by TFS after checking in. I also need to some how transform web config to the right connection for the deploy server.
Since this is a website but not a web application, thing becomes tricky. If you have done it before, please give me some idea.
Thanks
I have not done auto deployment with TFS but did automate the process with SVN. What we did is simply have the script deploy everything that had changed since last login to the web server - EXCEPT - the web.config.
Database scripts were handled by a process like this but those were not as reliable as the SVN code deployment was.
HTH
You could use a deployment tool such as kwatee (self promotion). Kwatee is configured via a web GUI and can then deploy any application or site via python scripts and transform files along the way.
You can use Visual Studio web deploy feature. ALM Rangers shipped a ready to use BRDLite Reference template for this purpose which you can download here. Also, check this link for documentation for the template usage.
If you're using VS2010, you can use a Web Deploy Project in your solution. TFS will talk to the WDP as it would with a web application's project file.
For config transforms, you can use a tool called SlowCheetah.
I'm basically wondering what the best way to deploy an Asp.Net Web Site is, mostly from the point of view of security. Right now, I'm trying to publish the website using Visual Studio 2010. Could someone direct me to a good tutorial on how to do this securely? For example, can it be done over an encrypted connection via Visual Studio? Is it necessary to install any software on the server to do this? Should I use a different program to open up an SSL (TLS) connection first, and if so, which program (does it come standard with windows)?
The server is running Windows Server 2008. Development is on Vista.
Many thanks in advance for any direction in this matter!
Andrew
I would publish the site to your local machine and file copy the files across to your test/production environment. As a rule we don't publish sites straight from VS to test or production.
For example you don't want to accidentally push things straight from dev into a live environment do you?
As far as the file transfer security goes you could use SFTP.
Note: First thing is to check with the owner of the server, as they often will provide you an FTP connection and will take care of configuring IIS.
If you want to add security, make a keyfile and sign your assemblies and consider running Dotfuscator on your dlls, the community edition is included in Visual Studio. Here is an earlier question where I've put more info on Dotfuscator.
If you have to do the deployment yourself, here's a few things to consider.
XCopy (easy)
MSI (have to create a setup program, you can do this easily in Visual Studio)
There is no security advantage in deploying using Visual Studio, but you can use Visual Studio to create a small setup program. One thing you want to make sure for security is DO NOT deploy any .cs files. Prepare your files, you should compile in Release mode, make sure debug is not enabled in your config file, keep your bin and it's dll, also the aspx, asmx, ascx, svc, css, js, and config files.
XCopy: Install a small FTP server, or use one your company alreayd has, this will allow you to get your files once you are logged into the target machine. You should be able to get an administrator account for the target machine, just ask the sysadmin of the domain, then log on using remote desktop, got to your ftp site, and download your files. Open IIS on the target machine, create a virtual directory and a pool. Copy your files to the location, configure your connection string to your DB if you use one, then test your website.
MSI: same process as above, except the setup will create the virtual directory and pool for you.
Here is extra info on best practices from the official ASP.Net website.
If you have some control on the server (e.g. to configure IIS7), you might want to look into Microsoft Web Deploy (new product just been released):
http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx
Haven't tried it myself, but looks quite slick and it apparently encrypts the data being copied up, so might suit you.
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.
Which is the best method to deploy a web application. Currently i am publishing the application and placing that folder in the server and creating virtual directory and providing windows authentication.
I just want to know this is a better metod to deploy or i need to use any other deployment technique?
Plese suggest
It really depends on the situation. For some situations, using Visual Studio's publish feature (right click project) works great. However in some situations, particular larger organizations or environments where the infrastructure group and development team are a little more isolated, you need to use a Web Application Installer or an MSI package. I've also had instances where the easiest thing to do was create a simple .bat file and create an external command in Visual Studio.
Use a web application installer, easy to create with Visual Studio.
If you need a third person to deploy your application in production servers, I would suggest you to deploy using a MSI, it would also help you to version your release.
MSI can be created using various ways including but not limited to
Deployment projects in VS studio
WixGen
Click once