I'm working on a fairly new project and we started from scratch. So not only the web application itself needs to get developed, but also the whole process of publishing the site and configuring the web server etc. need to be done from scratch.
This question might be more apropriate for serverfault, but that really depends on the answers. So, let's give it a try.
Wehn ever I publish our site via VS2008 (right click on the web site, publish web site, wait... done) I need to somehow tweak the process and trigger some other tasks, like:
- Copy some folders from my dav machine to the web server
- Delete the test database and let some scripts run on it
- and maybe some more I'm not remebering right now.
I was reading about the most obvious solutions like MSBuild, Powershell and VSTS2008, but I don't really want to dive deep into them until really I know, that theses tools can actually solve my problems. So guys, I'm pretty sure a lot of you have got a lot of knowledge about these tools or know even better ones. Please let me know. I really appreciate.
Thats my environment I'm living in:
- VS 2008
- VSTS 2008
- SQL Server 2008
- Windows Server 2008
UPDATE: Thanks for the great answers so far, but I'm especially looking for a solution integrated into Visual Studio Team Foundation Server as we're already using it for Source Control.
Cheers,
Steve
We deploy our web application with Subversion, and are very happy with it.
The build server compiles the application, copies it to a deploy directory and checks in changes to a Subversion repository. Okay, I admit that this is not trivial, but it's worth to invest here... because on the server(s) the deployment is now extremely easy. Advantages are:
Only the necessary files are copied to the server, the downtime is minimal (using svn update)
It's a piece of cake to verify what version is deployed to the server, and it's easy to have a consistent version across multiple web servers
If you screwed up, it's just 2 clicks to revert back to the previous version
It's takes care of deleting files when you deploy a new version. Copying a web application over an older version can leave potentially dangerous files
Modifications in the web.config are not overwritten by the deployment, they are merged. That's really a big plus
You can set pre and post build events, and can have one the events fire a script to complete your tasks.
You might look to see if the IIS Web Deployment Tool fits your scenario; it allows you to publish your website, configuration settings, database, etc... all together. This will also be integrated into Visual Studio 2010.
Related
I'm a web developer thinking of moving work on our largest client's site to a Git workflow, but I am new to Git and am not sure how to integrate it with our client's .NET servers and IT folks.
The current workflow is: a co-worker and I work cooperatively on local versions of the site files, which we then push via FTP to the client's development server (accessible via VPN). Once the changes on their dev are approved, we have to catalog every changed file and email that list to our client's IT team. One of their team then manually pushes the changed files from dev to their production server. We are not allowed any access to the production server, as there are enterprise apps on it as well as the public-facing web directory.
A bit more awkwardness comes from the fact that the client's IT guys are all .NET developers and we are a Mac shop. Fortunately, the site files are 99% HTML/CSS .aspx files, so they are easy for us to work with. Occasionally, the IT guys post an .ascx form control we have to incorporate, but for the most part changes travel from us to them.
As the site has grown, the labor of cataloging changed files has become a bottleneck and a point of potential failure. I want to automate deployment and provide revision tracking and rollbacks. From our side of the router Git looks like the way to go.
But what do I propose for the client side of the workflow? My understanding is Git is not native to .NET or IIS. I doubt I will be able to persuade our client's IT guys to install and use a new toolset. Their main job is enterprise app development, and I get the feeling they don't exactly live for the thrill of pushing our web updates live.
I am not sure if i understand you right. But git with .NET is pretty much the same as in other technologies.
Here is a git extension to use with Visual Studio:
http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c
Github is full of .NET projects.
I can't give you a advice to how to propose it. But git is definitly not a problem to use in VS or generally in .NET. They just have to switch.
You can also integrate git in your Team Foundation Server.
http://www.microsoft.com/en-us/download/details.aspx?id=30474
Git-TF is a set of cross-platform, command line tools that facilitate sharing of changes between TFS and Git. These tools allow a developer to use a local Git repository, and configure it to share changes with a TFS server. Using the tools, changes made in TFS can be pulled into a local Git repository, and changes made in the Git repository can be checked in to TFS. These tools can be used by individuals or teams collaborating using Git.
This way you could use both. TFS and Git for the same project. I think this could be a solution.
I know its possible to develop and host an ASP.Net site on Linux using Mono and Apache, but I'd like to know how well it works and if its worth the hassle? I prefer open source, but for this project I want the quickest, easiest, most reliable solution.
The site I'll be building will be a fairly basic ASP.Net site using MySQL.
I'd like to know if anyone else has experience using Mono in a situation like mine and how the project went. How did it compare to using a Microsoft-centric solution?
I know Mono is still somewhat incomplete, but I'm hoping I won't need the features it lacks.
This question may be a bit "polarizing". Most similar questions seem to have responses from people who are either very pro-Microsoft or pro-Linux. I'm hoping for some unbiased responses, preferably from people with experience using both.
I switched from MS-centric solutions about a year and a half ago and now I'm hosting all of my websites and web projects on Linux/Mono/Apache/MySQL based virtual servers (I was originally using nginx instead of apache, but mono-fastcgi-server was randomly causing thrashing, so I choose apache as a web server). I can summarize my (subjective) experience with this configuration into a few points:
It can take some time to get used to difference between Linux and MS based environments (if you never used Linux before), but I do not regret this decision. What helped me a lot was creating installation and configuration procedures for particular technologies (for example mono parallel environments, apache virtual hosts configurations, dealing with certain issues) which are mostly repeatable and can be automated.
You can still use Visual Studio to develop your applications and then deploy them on Linux machine. If you are using this approach it's a good habit to test your apps regularly on mono for possible incompatibilities.
I deploy web applications via FTP which is probably the easiest way of doing it (well maybe WinSCP is even easier, because you don't have to set up FTP server, but it depends on your preferences).
So far I have run into 2 cases with Mono/Apache where memory leak caused unavailability of the website. This was probably caused by Boehm garbage collector which I was using on old mono installation. I haven't had similar problems with a new sgen GC on recent versions of mono.
What I like the most on mono running on Linux environment compared to MS stuff is that you don't have to click around all the time when doing administrative tasks. Shell is for me unified administrative interface which can speed up things (if you have some practice).
Hosting ASP.NET on mono from my experience is quite easy and fast. i has been host multiple of my project using Mono ASP.NET MVC 1 / 2 using MySQL and PostgreSQL, serve by Apache mod_mono.
Compared with deployment on Windows Server. It quite narrow when using modern linux distribution which already provides all package to deploy mono ASP.NET. the only drawback is you have to make sure your Web Application portable enough in term of IO accessing and only very short learning curve and experience needed to debug and publish your project.
For Deploying our project in Linux. It easy using Version Control (VS) such as Mercurial or Git if u have fully control on the server. If U have more experience using continues integration is more better. I mainly using mercurial so step bellow is the step i usually do, but i think it almost similar for Git:
Install mercurial, and configure mod_wsgi, hgweb.wsgi and hgwerb.config
Init VS repo and publish at hgweb.config and configure hook to update and invoke xbuild to automatically build when u push it
publish the repo (web part) as mono application at mod_mono.conf
So u just need to code at visual studio, commit and push your changes using tortoiseHg without event login to server (set repo url, user and password at your repo hgrc)
Please note that although you can deploy ASP on Linux via things like Mono, if you use a Microsoft ide such as Visual studio, webmatrix, or Visual web developer your licence only allows you to deploy these on Microsoft servers!
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.
Currently, I'm maintaining an older ASP.NET website. In the solution, there exists 5 C# projects which build to assemblies as well as the development server's web directory. Normally, I do whatever work needs to be done (adding pages, making changes to existing projects, etc), build the projects (the current output path is my development server's wwwroot\bin\ directory) and if all is well, I open Windows Explorer and drag either .aspx or .dll files from the dev server to the production server. It's that last step that I'm wondering if there is a better way of doing. Does anyone have a different way of doing things where you don't have to leave Visual Studio to push updates?
You should add a Web Deployment Project, that´s (in my opinion) the easiest/best way to deploy a Asp.net app
Here´s an interesting article from the MSDN Magazine. http://msdn.microsoft.com/en-us/magazine/cc163448.aspx
ASP.NET Web Site Precompilation Overview would seem to be what you are wanting, yes?
Otherwise, there are web deployment projects for VS 2005 and web deployment projects for VS 2008 if you want a couple of alternatives depending on which version of Visual Studio you use.
How old is older? Are you using ASP.Net 1.0, 1.1, or 2.0, as those are what I'd consider older, but then I've been doing web development for over a decade.
You might want to consider creating a build script and a deployment script. You can look at using either Nant or MS Build, which are popular, or simply go with a batch file approach.
Some of the reasons I suggest going with scripts are:
1. You'll never forget to push that one file that you added
2. Either your build script or your deploy script should create a copy of all the artifacts need for deployment. This way, if you push out a bad build and need to roll back for whatever reason, guess what, you have a working copy tucked away somewhere.
3. Your scripts can run the installers (if you created a setup project) or they can simply copy out the files to the correct location, so that you don't have to have your dev box pointing to the right folder.
4. Sometimes you need to make changes to the configuration before you deploy... your scripts can also do this for you.
In general automating the whole process just makes it easier, faster and repeatable.
I need a little help on this subject.
I have a Web application written in ASP.NET plus I have the .bak file of the SQL Express database, my question is: How can I install this in a simple click and go way in the client?
how can I write a script that will create a new database, restore the bak file into that database, set up IIS and ... well, that's it :)
I do this all manually, and I do this a lot, so I was just asking if there is a way to prevent do all this steps manually.
Thanks.
You could use WiX to create a .msi that you can use to install your application at your clients. WiX takes a bit to get used to, but once you get the hang of it, you'll meet your needs above, and be able to extend them as your application grows or increases in complexity from the installation point of view.
I read your question to mean you have several clients where you install your application, if that is not the case, and your app exists in one place, there are better solutions, and better people to give them to you!
While WIX is certainly very flexible if you aren't comfortable with the learning curve (and there is a bit of a learning curve IMO) then perhaps you should check out the Web Deployment Projects.
From the blog post:
Web Deployment projects can be used with either the "ASP.NET Web Site" or "ASP.NET Web Application Project" options built-into VS 2008, and provide a few additional build, packaging and deployment options for you to use.
Regarding the database, I'd suggest that you utilise the App_Data directory and just deploy the ".mdf" file. This would be easier than trying to create a new database and restoring a backup.