Consider a .csproj containing the following directive:
< Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
There's a standalone TFS Build service installed on a machine, with a default Controller and one Agent. The TFS components were installed; Visual Studio was not installed.
When compiling an ASP.NET MVC 2 Web Application (targeting .NET 4), the TFS Build service encounters an error:
C:\somepath\foo.csproj (219): The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
TF270015: 'MSBuild.exe' returned an unexpected exit code. Expected '0'; actual '1'.
It's true: there's no sub-directory "WebApplications" in the "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0" directory.
It seems that this subset wasn't included in the install of the TFS Build service. TFS doesn't give any options on what pieces are installed for Build service.
What's the most appropriate way to install these artifacts, and any dependencies, on this TFS Build machine? Could this have been avoided?
Have you tried creating the path C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\ manually and copying the file Microsoft.WebApplication.targets there? If Microsoft.WebApplication.targets doesn't contain references to some specific build tasks that should do the trick.
At least that worked for Visual Studio 2005.
Check for unwanted references like 'stdole.dll' in your references and remove it.
connect to tfs again (to refresh)
try to build again.
Best solution is to always install VS2010 on your build machine.
Related
In TFS Test Task I know that I can manually set the location of vstest.console.exe via:
this is less than an ideal solution though since, as I update my build server, this location may become invalid. The problem that I have run into is that if I select 'Version' my build server ends up using the vstest.console at this location:
C:\Program Files (x86)\Microsoft Visual Studio\2017\ SQL\Common7\IDE\CommonExtensions\Microsoft\TestWindow
I am guessing that this SQL Folder is the SQL Server Data Tools folder that is installed on the build server. This folder location isn't generally a problem, vstest runs my unit tests and reports back on them, however, it doesn't produce a code coverage report. I initially thought that this was due to an improper configuration of the builds, however after verifying that the build was setup correctly and that the server had all of the necessary dependencies I started looking for other causes. I opened up the .trx file from one of the builds and noticed that the DataCollector logged a message that it couldn't find CodeCoverage.exe. After some more troubleshooting, I pointed my build to the location of the vstest.console shown in the image above and everything (tests, code coverage) ran fine. This leads me to believe that vstest expects the path:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Dynamic Code Coverage Tools
to exist relative to where it is run from and that directory (Dynamic Code Coverage Tools) does not exist inside the SQL folder.
Is there a way to change the path that TFS uses when the 'Version' checkbox is checked?
VsTest task uses vswhere.exe in order to determine the latest version of VS installed in the machine. Can you try to run vswhwere.exe and check which version of VS is installed at C:\Program Files (x86)\Microsoft Visual Studio\2017\ SQL folder and is it higher than other versions, also check whether its an enterprise installation or not. As code coverage is provided as part enterprise installation only.
You will be able to find vswhere.exe in agent working folder as per VSTest task version eg.
C:\Temp\Agents\127Agent_work_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\2.3.19\vswhere.exe
I am trying to set up an automatic build.vnext process for TFS 2015. This build process contains one Visual Studio Build build step, in which a .nupkg package file is created in the build agent's bin/Debug and bin/Release directories.
I have a private NuGet-Server installed on the same server as the build agents are running on. I want to copy the generated .nupkg files from the bin-directories to my NuGet-Server's package-source-folder (say C:\Packages).
How can I do this with TFS 2015 Build.Vnext/Preview?
Edit:
I can easily copy all build output from the agents to the package folder by configuring the Visual Studio Build options "Copy to Staging Folder" Search Pattern to **/bin/*. This copies the folders myProject\bin\Debug and myProject\bin\Release folders and their contents to the package folder.
If I specify e.g. **/bin/**/*.nupkg or similar, nothing is copied, even though a respective *.nupkg file exists.
I found a solution to this problem:
Under Options set Copy to Staging Folder of the Visual Studio
Build-Configuration to true.
Use the search pattern **\bin*
Add a Command Line utility definition.
Let it execute C:\YourPathTo\nuget.exe with the arguments push C:\YourStagingPath**\bin***.nupkg -s [YourServer] [YourAPIKey]
Done.
I've just setup a TFS (2012) server and now I'm trying to build the complete code (written in .NET 4.0 in VS 2010) via the TFS Build server. But in my solutions I have also a WCF RIA project which contains linked files because they are used somewhere else also and there is no possibility to add a reference to a general .NET binary in WCF/Silverlight.
Everything builds without any problem on my development machine but when I check it all in, create a standard build definition and run that build definition I get the following problem. The linked files have usings (UsingNamespace for example) to other projects that are also build by us and build before the WCF/Silverlight but the following error pops up while building through TFS Build server:
The type or namespace 'UsingNamespace' could not be found (are you
missing a using directive or an assembly reference?)'
Is there any solution for this problem that I looked over?
EDIT 1
Just tried to set the Copy to Output Directory propertie of the linked files to Copy Always but this still gives me the same error as I was expecting. The problem is that the linked file is placed somewhere that it can use the usings but the WCF RIA service cannot access/find that using.
EDIT 2
Just tried out my local test TFS where I can do what I want and there I made a build definition with just the solutions needed to make that the project with the linked files builds. This worked without any problem. Then I tried the same on our TFS server with a new build definition that has the same solutions as on my test TFS and here it did not work. The only difference that I know for sure is that my test TFS is TFS 2012 Update 1 and that my production TFS does not have the update 1 yet. I'll try to install it next week.
EDIT 3
I've just updated our production TFS to Update 1 but it is still not working with my temporary build definition which only contains the projects that are needed to build the silverlight application with the linked files. The 2 workspaces are the same on both server and the projects to build are also the same.
You need to specify the workspace information in the Build Definition for the build to use. The workspaces are what the build process copies from source control to the build server. If you don't have everything in the build server's workspace, it can't build properly.
The Source Control Folder in the workspace tab is the location of the files you need from TFS. The Build Agent Folder is a relative path from the build server's pre-defined base location. You'll usually use $(SourceDir)\Folder to specify the "Folder" that your build process needs.
This sounds like an $(Outdir) problem. A build definition in TFS automatically overrides the Bin folder. All Binaries are redirected to the bin folder upon compile. Sounds to me that you are using a mixture of project references and file references. The file references are probably what is causing your build failures.
Example if you compile in the same build the following solutions
Solution1.sln (TFS Build Pass)
project1.csproj
project2.csproj (references project 1)
Solution2.sln (TFS Build Failure)
project3.csproj (references binary output of project 1)
Expectations from TFS out of the box without customizing your workflow is that this simple build will fail. The reason is that in your development box all projects produce output to one destination while in a tfs build your projects will build to $(Outdir).
Some Things to try
Simple (best practice in my view)
Create 1 solution and use project references instead of file references.
Complex
Build using MSBuild project files
Modify your windows workflow to not override the $(Outdir)
Copy the binaries after a build is complete.
Best practice on Automating Builds
Build from command line
Build from cmd a NON vs2010 command line.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe FullpathtoSolutionFile.sln
Cheers!
Apparently there was just missing the WCF RIA services V1.0 SP2 on the TFS server. If that was installed the problem was solved.
I have a website, a windows service, and some shared class libraries in a single Visual Studio solution. I use Octopack on both the website and windows service, and on my machine these builds work as expected.
When using the TFS Build Server, the website nuget package is generated as expected, but the windows service nuget package contains all files from the website, as well as the service. E.g. it includes the _PublishedWebsites folder as well.
This is because TFS uses a single location to build projects.
What is the best way around this?
I know this question has since been closed, but I cam across this issue and solved it in a different way.
My solution is compromised of a number of websites and windows services and had the same issue of the OctoPack created nuget packages including all the solution assemblies from the 'pooled' output folder when building with Team Build. The reason the nuget packages get all the assemblies is OctoPack uses the outdir msbuild argument as the location to include assemblies from.
The way I got around it was to use the msbuild argument GenerateProjectSpecificOutputFolder=true. This instructs Team build to create a folder for each project in your output folder in the same way Visual Studio uses the bin folders under each project when building locally.
My build definition msbuild arguments looks like:
/p:GenerateProjectSpecificOutputFolder=true;RunOctoPack=true;OctoPackPublishPackageToFileShare=\\<NugetServer>
I currently just push the packages onto a shared folder but the OctoPackPublishPackageToHttp and OctoPackPublishApiKey parameters can also be used.
The benefit of this solution over the one above is you don't need to specify the files to include the nuget package.
Hope this helps someone.
I ended up using this nuget package to ensure the console app built to a seperate directory on the TFS server.
https://nuget.org/packages/PublishedApplications/2.1.0.0
I then had to specify in the nuspec file, which files should be included for the console app. e.g
This works and I can now deploy using Octopus deploy.
The downside of this apporach is that the PublishedApplications build only works on the TFS build server, so I can't build the project locally in release mode. Still looking on how to overcome this.
I have a VS2010 TFS Build server configured with a build definition set for continuous configuration.
For my BizTalk 2010 solution I have 200+ tests. These tests all run ok on my dev box but on the build server, for the tests dealing with flat-files, I get the error "Unable to find Microsoft.BizTalk.Tom.resources". My guess is that this is a resource file contained within the assembly Microsoft.BizTalk.TOM.dll Although I've used reflector and can't see the resources.
It turns out Microsoft.BizTalk.TOM.dll is a .Net 2 dll that is installed with BizTalk into the following folder:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies
I've checked the build server and confirmed that this assembly is present, in the above folder.
I have tried the following, based on 3 different blog postings around the same issue:
Included a reference to dll and set copylocal to true
Added the assembly to the .Net 2 GAC
Added the assembly to the "Additional files to deploy" list from the Test Settings dialog / Deployment tab
Added the assembly to the "Folders to use when tests are run" list from the Test Settings dialog / Unit Test tab
After the tests fail I check the \TestResults\Out folder. I can see that the Microsoft.BizTalk.TOM.dll has been copied here.
When I check the equivalent folder on the dev server I don't see any files that aren't present on the build server.
Any ideas what I can try next please?
I found a copy of the Microsoft.BizTalk.Tom.dll in the folder: C:\Users\tfs_service\AppData\Local\assembly\dl3\randomname\
After researching, it turns out this is where "Shadow Copies"of assemblies are stored: what is cache AppData\Local\assembly\dl3?
I would like it know why shadow copies are being made and how I can prevent it, I guess in my case the app domain is MsTest?
I deleted the shadow copies and uninstalled from the GAC, so that I was left with copies in only the following folders:
C:\Program Files (x86)\Microsoft Visual Studio
10.0\Common7\IDE\PublicAssemblies
C:\Program Files (x86)\Common Files\Microsoft BizTalk
After deleting the shadow copies and and restarting the server, the tests now run successfully.