On my development laptop I have only VS2012 RC installed, and I am successfully able to hook into the new MSDeploy .pubxml plumbing (DeployOnBuild and PublishProfile settings) from powershell (via psake) to deploy my web site to our test server.
However, on my build server, I initially had VS2010 SP1 installed, and I've now additionally installed the 2012 RC (I have other builds on this machine that are still .NET 4).
When running the same script with exactly the same parameters, I see different results between my dev machine and the build server. The command I'm running is
exec { msbuild "Website\WebSite.csproj" /m p:DeployOnBuild=True /p:PublishProfile=MyTestProfile }
On the build server, this does not in fact trigger MSDeploy, but simply the packaging bits that zip the site up and makes a deployment package. My machine successfully picks the pubxml file up and does a successful deployment.
Eventually, I believe I've traced the problem to the file Microsoft.Web.Publishing.targets. On my dev machine I have only
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web
but the server additionally has
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
and it seems like this file (without knowledge of the .pubxml stuff) is what's being used there.
Has anybody got any idea what I need to twiddle (preferably within my own msbuild files so I don't screw up anything else on the build server for the 4.0 builds) to get msbuild to pick up the v11.0 version of the file and thereby use my .pubxml file?
That is interesting it should be picking up the latest (v11.0), seems like there is a bug here . This is controlled by the MSBuild property VisualStudioVersion.
Here are the rules for how this value is populated at build time.
1. If VisualStudioVersion is defined as an environment variable or a global property (e.g. /p: on the command line) that wins. This is how Dev11 & the Dev11 command prompt are always v11 – they both define VSV as an environment variable
1. Otherwise, if there is a sub-toolset that matches the equivalent solution version (which is currently always file format version – 1), choose that
1. Otherwise, get the default version; 10.0 if Dev10 is installed, Highest-versioned sub-toolset version installed (currently always 11) otherwise
In your case since you are running into an issue you can pass in the property /p:VisualStudioVersion=11.0 to ensure that the correct targets are used.
Related
Hi I am banging my head for last few days.
Here is the situation ...
1. I have VSO account which maintains the TFS in cloud.
2. Installed a build server/agent on another machine. (Works fine)
3. Tried to build(XAML build) one solution using that server/controller.
4. Got an error saying ...
"The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk."
The build server and the agents are from TFS 2015 and the project is a Visual Studio 2015 project using framework 4.6. I was expecting "v14" folder for target files during build. Why it is trying to find things from "v11" folder ? And how do I solve this.
I know I can copy files to "v11" but I don't want to escape the facts. There should be a reason and a proper fix. Any help would be nice.
Several solutions for you to correct this error:
S1: Install MSBuild.Microsoft.VisualStudio.Web.targets from NuGet gallery via running the following command: Install-Package MSBuild.Microsoft.VisualStudio.Web.targets.
Then replace the following line in your .proj file
<Import Project="$(MSBuildBinPath)\Microsoft.WebApplication.targets" />
with
<Import Project="$..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0\tools\VSToolsPath\WebApplications" />
S2: Set the /p:VisualStudioVersion=12.0 MSBuild argument in the build definition.
S3: Copy the Microsoft.VisualStudio.Web.targets file to the C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications folder on the build agent machine.
S4: Install VS2012 on the TFS build agent machine just like Patrick mentioned above.
And related cases: Microsoft.WebApplication.targets and Microsoft.WebApplication.targets was not found, on the build server. What's your solution?
The WebApplications\Microsoft.WebApplication.targets (11.0) (which comes from VS2012) is referenced in your web application, so the Visual Studio 2012 should be installed on your build server to resolve this issue.
Be note that, to guarantee TFS build runs successful, you should make sure your build agent machine has the some environment as dev machine.
Did you restore a previous collection on TFS 2015 from a previous TFS version? Did your solution or any projects in your solution get created prior to VS2015?
I would like to create a setup project based on WiX which does the following (as well as creating the installation package):
callable from msbuild running on a CI build server (Hudson)
take a version number from some asset in either the setup project or the main assembly
take the current build number from the CI system
create a full product version number [version].[build] such as 1.3.432
store this value in an asset (e.g. the main assembly) is such a way that it can be read out at run time and displayed on the splash window
I have tried a number of approaches and googled a lot but have not found a workable solution. Can anyone help?
The WiX toolset does this by creating a version.cs, a version.h and a version.wxi during the MSBuild then including those files in all the projects. That way our executable can print out their version when you run something like candle.exe -? and all of the bundles and .msi packages have their versions set correctly.
You can see how we do this in tools\WixBuild.Version.targets (here). It would straight forward to override the properties in WixBuild.Version.targets with properties passed via the command-line to MSBuild via Hudson if you wanted.
From my local machine to a development server, Web Deploy 3.0 works fine with Visual Studio 2012 publish profiles using the following command:
msbuild .\myproj.csproj /verbosity:d /p:DeployOnBuild=true;PublishProfile=Develop;VisualStudioVersion=11.0;AllowUntrustedCertificate=true;username=xx;password=xx
When running this same command from the CI server (happens to be Jenkins but this should apply to any), the command finishes successfully, but no web site is ever deployed.
When comparing the log output, a large section appears to be skipped by the build server. It is occuring just after the 2 lines listed below (these 2 lines of output are identical when running local or on the CI server):
Target "PrepareForRun" in file
"C:\windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets" from project
"C:_Application\proj\src\proj.Web\proj.Web.csproj" (target
"CoreBuild" depends on it):
Done building target "PrepareForRun" in project "proj.Web.csproj".
When running locally, this is followed up by what is shown below (plus hundreds more lines of logging):
Target "InsertAdditionalWebCofigConnectionStrings" skipped, due to false condition;
($(InsertAdditionalWebCofigConnectionStrings) And '#(_ConnectionStringsToInsert)' != '')
was evaluated as (True And '' != '').
Target "_CleanWPPIfNeedTo" in file "C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets" from
project "C:_Application\proj\src\proj.Web\proj.Web.csproj"
(target "PipelineCollectFilesPhase" depends on it):
Task "ReadLinesFromFile"
On the CI server, this directory appears to be missing:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets
Would a missing targets cause it to fail silently? Where does this folder come from (missing the entire Web folder on the CI server)?
Have you installed Visual Studio on your build server? It seems like a strange thing to do at first (and isn't strictly necessary), but it certainly in the easiest way to resolve all these issues.
You can manually copy the required targets files from your PC on to the build server, but you'll be playing a trial and error game to get it to work.
Also if MS release new out of band updates, like Asp.Net and Web Tool 2012.2 which they did recently, it's a much easier install procedure for the build server than to try and work out what targets have changed and copy them up manually.
Let me know if this helps.
I just downloaded TeamCity 7 today and decided to get it up and running for my Azure solution. I am not trying to do anything fancy (yet) and started with a very basic command line build:
msbuild /t:Publish /p:Configuration=Release;TargetProfile=Production;PublishDir=S:\HoursTracker\Deployments
This builds successfully and produces a package that looks like this*:
I then attempted to configure TeamCity in an identical fashion:
This builds successfully and produces a package that looks like this*:
What I don't understand is why there is such a huge discrepancy in the size of the MVC project. Publishing directly from Visual Studio produces the exact same result as my MSBuild command so I'm convinced that TeamCity is the odd man out. Since I assume TeamCity is not broken, can someone please educate me on how to properly configure it so that I get the expected output?
*I have renamed the package files with .zip so that the details were viewable for this post.
Ming's answer helped me solve the mystery. After inspecting the contents of the zip files, I discovered the difference was that my MSBuild package contained bin and obj folders and the TeamCity package did not.
After making this discovery, I realized that I could specify multiple targets to MSBuild and prepended "Clean" to my targets switch like so:
msbuild /t:Clean;Publish /p:Configuration=Release;TargetProfile=Production;PublishDir=S:\HoursTracker\Deployments
As expected, this removed those folders. So apparently, TeamCity specifies "Clean" implicitly for you. Mystery solved.
Windows Azure packages may be larger than we expect. You can rename the cssx file to zip and you will find out what’s inside the package. In addition to the web application’s usual files, there’re a bunch of Windows Azure files. For example, if you enable diagnostics, you will see a diagnostics folder, where you’ll find files used by Windows Azure diagnostics runtime.
Best Regards,
Ming Xu.
Why you specified x64 for msbuild runner? Try selecting tools version as well. You have not specified /p:Platform parameter. Does publish task involve rebuild?
TeamCity starts msbuild with number of /p: parameters taken from " properties and environment variables " section, plus some well-known parameters like configuration name or project name.
In prior versions of MSBuild, you could set an environment variable named MSBUILDEMITSOLUTION to 1 to get an XML version of a solution (.sln) file that could be parsed. According to the MSBuild Team Blog, that's still in the version that ships with Visual Studio 2010, but it does not seem to be working.
Has anyone managed to get this working with MSBuild 4.0? If so, what is required?
(We use this to find and run convention-based unit tests with an NAnt script.)
Set MSBuildEmitSolution=1 and then build from the command line. You should then see a MySolution.sln.metaproj file near MySolution.sln.
Notes:
If you open a command prompt window, then set the env var via System Settings, you will have to open a new command prompt.
You'd think you could also use msbuild /p:MSBuildEmitSolution=1, but you can't.