I am using Visual Studio 2012 Professional to deploy my ASP.Net MVC website.
The problem is that when I use the one click publish feature, my web application comes to a screeching halt and it takes about 5 minutes for the website to respond normally again.
What are some things I can do to speed up this process to reduce or eliminate the amount of downtime for my users?
I publish to a separate copy of the site on the live server and I have a script which I then run on the server to compare the live site with the copy and only update new/changed files/directories and delete removed ones. This cuts down the downtime quite a bit, especially if there have only been minor changes.
Related
I am planning to introduce gated checkins in TFS 2015 for our project. Our product consists of one database, one web service and one web front-end.
The database “build” and deploy take like 60 minutes. When that is done we generate C# source code for our Web service using meta data in the just deployed database.
We the build the Web server and start it.
Next step we generate C# source code for the Web front-end using the services in our running Web service.
Now, I would like to avoid building and deploying the database whenever possible. I other words I would like TFS to “ask me”, custom script of software” if the database should be built and deployed. This could be done using C# code, perl, python Windows batch file or other scripting/coding, exit code 1 is perform the build, exit code 0 don’t or whatever.
So, basically some feature in TFS that conditionally performs a build. I guess it could be two different builds, one with all steps and one with just Web service and Web frontend build. Please note that the database build is just a set of plain Windows batch files, two files to be precise.
Is this supported in some way?
I am trying to work with Visual Source Safe while developing an ASP.NET MVC 3 site in Visual Studio Web Developer Express. There doesn't seem to be any integration between VS and VSS so I have to check in and check out manually.
During the course of a day, I create and modify many files, and so it is annoying to have to do VSS checkin/ checkout every time. Is there anyway to, instead, just check in the entire site at the end of the day?
That way, I will have a working copy of [Monday's] version of the site, and on Tuesday at the end of the day I would have a working version of Tuesday's version of the site. Then, can these be deleted over time?
The express edition of Visual Studio doesn't provide any integration with VSS. If you'd like to do the check-in/check-out directly in Visual Studio, I recommend you upgrade your VS.
Also, you can take advantage of the VSS command line. You can execute the command to check in the entire site at the end of the day, and perform check-out on the next day.
http://msdn.microsoft.com/en-us/library/asxkfzy4(v=vs.80).aspx
Although the command line may simplify the process, I still recommend you check in the modifications in time.
I'm trying to set up a TFS server for our small dev team, and since this is fairly new to me I have a couple of questions.
1) We are developing ASP.Net websites for internal use (intranet etc), these websites currently are not saved with visual studio solutions, they get saved basically as they are on the server and we just update them using Visual Studio by doing file > open website.
So my first question is should I save these as solutions in TFS? What would the benefit of this be?
Im coming from a background of developing WPF applications and have always seen everything saved with a solution in TFS.
2) What should we store in our TFS repository (and what should we exclude)?
At the moment I am storing source code & Documentation but is it really appropriate to store things like installers for VS plugins / small applications or should this kind of thing all be placed on a server someplace?
So my first question is should I save these as solutions in TFS? What
Yes, you could create a solution containing the different ASP.NET web applications.
would the benefit of this be?
Your source code will be version controlled
What should we store in our TFS repository
Source code, third party assemblies that your ASP.NET applications might require, script files, basically everything that allow to get your site up and running. Documentation should also be stored along with the project. Same stands for installers (the source code only, not the MSI) if those installers allow to deploy the ASP.NET application on the live servers.
and what should we exclude
Compiled assemblies, but they are automatically excluded by TFS anyway.
I am using Windows server 2003 OS.I have built SharePoint webparts in VS2010 for SharePoint 2007.Each time I deploy from the WSP project it takes few minutes to deploy it to the SharePoint site. This is considerably annoying since each time when the webpart code is changes it will take lot of time to deploy. It become very hard for the development and testing purpose.Can anyone suggest if there is any way to make the deployment faster?
Thank you
Consider deploying your web part to the bin during your dev process (using a post build xcopy or something similar). It'll speed you up massively. You'll still need to test your WSP deployment.
So, I'm currently in the process of moving a client from Surround SCM to TFS. For some reason unknown to me they have a really hard time setting up a dedicated IIS for the app tier of TFS. Now they already have both an IIS and a SQL server for their regular intranet/internet apps, so I thought why not sjust use the existing server?
So my question is: Would it be ok to install TFS App Tier on the existing IIS server or reside on its very own dedicated server?
TFS should live fairly happily with other IIS applications however you must have your Sharepoint instance configured to be equally happy with other services. TFS is not happy if installed on a domain controller, but provided IIS has all the pre-requisites, this is the only TFS AT on that server, no other sites in IIS are listening to port 8080 and you keep the TFS instance in it's own application pool then I think things should work out but I have never done it in that order. I've had additional applications running on the IIS instance set up for TFS when TFS was set up first - but not add a TFS instance to an existing production IIS instance.
That said, I would be very tempted to have TFS on it's own IIS instance. As the version control and work item tracking system is usually fairly critical to the life of a software development organization you want to make sure that this critical server is not affected by other applications in the organization. You want it to have the love and attention given to a production environment. Also - when you are getting started with installing TFS you can sometimes run into issues. Being able to wipe the box clean and start all over again ensuring you are following the installation instructions step by step is a handy fall back position (more true in the TFS 2005 days than now, but old habbits die hard).
Additionally, TFS comes with a license for SQL Server provided that SQL Server instance is only used for the TFS application.
Because of all this, I would rather have a TFS server running the Application Tier and Data Tier on the same server than have an AT on a share IIS box. I think I would even rather have the application tier running on a virtualized environment running on that shared box.