I have a TFS 2017 Update 2 on-prem server with VS 2017 Enterprise installed. Our Build contains a Unit-Testing project which contains a Fakes assembly and works locally on the dev machines.
When build on TFS, the build fails with
The type or namespace name 'Fakes' does not exist in the namespace
'Our.Product' (are you missing an assembly reference?)
(i.e. misses/fails to generate the Our.Product.Assembly.Fakes.dll file)
I have additionally set up Fakes as suggested here.
What baffles me is that there are no mentions of Fakes in the build log (except for the error itself and the paths where MSBuild looks for the file), even with debug verbosity. He doesn't event try to generate the Fakes assembly.
Are there other steps I need to take? We use the vNext build definitions.
Update:
This is the build step that works now, before the /tv:15.0 /p:VisualStudioVersion=15.0 were not there.
Update
Use the latest version for msbuild arguments such as /tv:15.0 /p:VisualStudioVersion=15.0 could solve this issue.
First try to use build service account RDP to remote build agent and manually run the build to see if the assembly generated.
This will narrow down if it's related to your environment on the build agent. Make sure it's the same as your locally dev machines.
If the assembly is also generated, then the issue may related to your build definition settings. Check if you are using the right msbuild version. For vNext build, also enable verbose Debug Mode with system.debug=true
Related
I currently have an on-premises TFS 2017, a TFS build and a test that fails on the build agent but not when running locally. I heard about historical debugging but I couldn't find instructions on how to enable it on a TFS build, if that's even possible.
Is it possible to configure my build so that it generates an intellitrace file for me to debug the test run afterwards?
For intellitrace which related to the old testsettings file and could add some variables to configure this.
You could also manually enable such option in the VS on your build agent.
Also find a link mentioned it seems also work with Msbuild arguments. Even not documented anywhere in Msbuild command doc. I wonder whether IntelliTrace is still running even though it's not explicitly specified to do so
However, looks like you just want to find the root cause why your tests failed on tfs build even it passed locally.
To narrow down the issue, suggest you directly remote to your build agent. Instead of through TFS build, manually build your project, run the tests in the Visual Studio on build agent.
It will come out whether it's an environment issue. You must make sure it's the same environment for build agent and your local.
TFS is just using build service account to invoke msbuild/vstest command in build agent to run build/test.
Also make sure build service account have appropriately permission if your tests required some permission.
When trying to run the unit tests as a build step in TFS Build 2015 (vNext), I get the following warning:
Warning: Unable to create DiaSession for <assembly>
No source location data will be available for this assembly.
The test assembly is then run, but the unit tests inside fail because they can't locate the references, I'm assuming because of the 'No source location data will be available' part of the warning.
The NUnit NuGet package I am using for the unit tests is: "NUnitTestAdapter.WithFramework" v2.0.0. The project is made in C#.
I've seen this question, but I don't really understand what they are saying, and it doesn't look like they are using TFS Build 2015 (vNext) build definitions.
Any ideas?
The question you referenced is talking about the old TFS build XAML not vNext build the one you are using.
However you could also use the same MSBuild arguments in vNext Visual Stduio Build or MSbuild task.
You need to use add the /p:NoWarn=warningNumber in MSBuild Arguments
in the build definition. Or use the /p:WarningLevel=0 argument to
suppress all warnings.
According to your error info, seems the issue should not related to TFS build side. Since unit tests inside fail because they can't locate the references, please try to directly run your tests on the build agent locally(remote to). This will help you to narrow down the issue. Besides, also Enable Verbose Debug Mode for TFS Build vNext by adding system.debug=true to see if there are more details log info for troubleshooting.
I have installed TFS 2018 Community and was trying to publish a project to plesk domain using one of the publish profiles in the arguments of msdeploy task as shown in the picture below but it only build the project but did not publish it like I thought it would
Generally if you can run the msbuild command successfully with the arguments on local VS, then it should be also available in TFS.
So, please check below things to narrow down the issue:
Just make sure you have the same components installed and configured
on your build agent machine.
Make sure you have the correct configuration for your build
definition.
Based on your screenshot above, just try to set the correct buildPlatform and buildConfiguration (consistent with your project settings in VS).
Also verify that if you have checked in the PublishProfiles, and check the first Get sources step, make sure the system can get the sources and PublishProfiles during the build process.
This article for your reference : TFS 2015: deploy website to IIS without installing extra add-ons to TFS
UPDATE:
In order to use Publish Profiles on the build server, you have to have some of Visual Studio's prerequisites. Make sure you have installed the full version of Visual Studio on the build agent machine.
Besides, you can try with below arguments (Just change the PackageLocation value accordingly) :
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
Referecne: Working with Web Deploy and Release Management for the deployment.
I have a build definition in Visual Studio Team Services (a.k.a. Visual Studio Online? I'm not really sure the right name for it honestly) that is not producing an artifact, and I'm really not sure why. The main project in the solution file is a Windows service that is built using TopShelf. I suspect that maybe the MSBuild arguments in the Visual Studio Build task might be wrong. I copied them from a build definition for an MVC project that is working, but it occurs to me that they might not work for a Windows service.
Here they are:
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true
/p:PackageLocation="$(build.artifactstagingdirectory)\\"
I have a Copy Files task and a Publish Build Artifacts task later on in the process, but apparently the $(build.artifactstagingdirectory)\\ is empty. I get this warning:
##[warning]Directory 'd:\a\1\a' is empty. Nothing will be added to build artifact
Oddly enough, in another task in the process where I publish the symbols, everything appears to go off without a hitch.
One more bit: I'm using a hosted build agent. Not sure if that matters or not.
That's all of the pertinent information I can think to provide. Am I way off base here? I've used Octopus Deploy in the past and I know I had to install Octopack on my services. Do I need to do something similar here?
You don't need any of those MSbuild arguments; most of them apply to ASP .NET projects and will do nothing for a console application.
Replace them all with /p:OutDir=$(Build.ArtifactStagingDirectory). That will tell MSBuild to put the build outputs in the artifact staging directory.
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.