We're using this process to use WebDeploy to deploy and compile two web sites that are a part of the solution. The approach we took was found here:
http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html
But it's only deploying one of the web sites; is there a way to tell it to publish both?
Thanks.
Web Packages created based on the above walkthrough (i.e. via VS 2010 and its derivatives like TFS etc) can only contain one web project. Unfortunately VS generated Web Packages will be limited from this sense. If you use Web Deploy (MSDeploy) EXE or API directly and then you can package more than one web site within IIS etc. I believe you are trying to accomplish this via Team Build so that is not really an option.
Although, in Team Build you can create more than one build definitions to cause multiple packages to be created. You can also set properties in your .csproj or .vbproj file (same properties mentioned in Step10 of the walkthrough). If more than one project have properties DeployOnBuild set to be true then from within single solution build within TFS you can have multiple web packages generated. You will still have to deploy each web independently.
Hope this helps
Related
I have a web application (C# and Angular). There are two folders called "Views" and "Resources" which will be different for each customer. I would like to have them all under TFS. Any suggestions?
I would create a single set of Views and Resources that excersize the functionality that you are building for all customers.
You should use an automated build to package your vanilla site and deploy it to your development server continuously. Ideally you should package your vanilla site as a zip or Nuget package.
Then, in a separate folder (TFVC) or Repo (Git), you create a resource/view set for a customer. Have your solution pull the packaged vanilla site and unpack it (so it'snot under source control here) and let'syou run the site for development.
Package and publish each customers customisations along with the vanilla site.
Now when you go to ship to a customer you can have a script that pulls the vanilla+customer packages and deployes the site.
If you want you can publish the bits to a known and accessible location and have your site self update.
You might also leverage the release management tools to deploy.
I have two web servers that I am testing with some MVC applications. When I create a build definition in Visual Studio I would like to utilize two drop folders (one on each server) but this doesn't seem possible. I know there are a lot of ways around this by manually copying the files, setting up a data replication or creating multiple build definitions but I am looking for the simplest way. Any ideas?
Add a post-build script that will copy the files to the second web server.
The result of a build is always one drop folder, however you will get a subfolder for each web application(look in /_PublishedWebApplications/MyWeb/). As either a post build PowerShell, or as a release management activity you can have both of those web applications deployed to one or more servers.
In the default build template there are place to call PowerShell. You should use the post-test location to call a script that deploys your apps.
If you have a progression of environments, like dev->qa->prod, then you can use the release management tool to create a pipeline for each or both of your applications.
I'm trying to design a WIX setup project that needs to harvest the output of an ASP.NET MVC Web site.
There are several problems.
Building the ASP.NET project does not output the same content as a web publish would.
So it seems that I need to harvest the output of the published web site, meaning it should be done in a temporary location.
It should work on team build continuous integration (and in Visual Studio).
Every sample I've found so far uses temporary directories and command line steps before building the setup project.
Am I wrong ?
Is there another solution ?
Thanks in advance.
You would need to run those commands as part of your build so that you have that output to then package with WIX.
I have several websites that I manage for a company and they want me to transition to TFS. As part of their policy, I can only deploy files that have changed since the last deployment. I.e. if a view has changed then it gets deployed, if it has not changed then it not part of the deployment package. They use automated tools for the deployments.
Currently I use a custom tool I wrote that hooks into my local source provider (Vault Pro) and finds all the changes from a given date and copies those files to a zip file.
How can I accomplish something similar with Team Foundation Server?
TFS provides you with an SDK that you could use to query it from code. Here's the documentation of the client API.
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.