I have following tools installed on my machine:
TFS 2017
Visual Studio 2017
MSBuild 14.0
In my application, I'm using some C#6 elements like string interpolation ($).
When I try to build it, controller says that it could not resolve the symbol.
Builds fail for both XAML and standard definitions.
In build logs, there's an information that it uses correct MSBuild 14.0 path: C:\Program Files (x86)\MSBuild\14.0\bin, but still failes to resolve C#6 elements.
I would really appreciate if you would help me with this problem, I've searched entire internet and found nothing :/
If you guys need any information, I'll be more than happy to provide it. Thank you.
TFS with XAML build is just using MSBuild to run the build. You could first try to use MSBuild command to run the build test locally, which will narrow down the issue.
If it works well on your dev machine and not works from a TFS server build. Very likely the environment problem.
To make sure the build successful, you should keep your build server environment the same with your local environment. Please double check this.
For trouble shooting, you could try to remote to your build agent, manually run your build and test on your build agent.
As for how to enable C#6, you could also refer this similar question, modify TFSBuildServiceHost.exe.config file which may do the trick. How do I enable C# 7 builds in Team Foundation Server 2015?
If you still get error, please include detail build failed logs here.
Related
We're just in the process of transitioning from VS2013&15/TFS2013 to VS2017/TFS2017 (on-site TFS, not VSTS) and the first test solution is a dotNet Core 1.1 based one (a multi-project web service).
The solution builds fine on the original developer's box and I've got it out of TFS and it builds fine on mine too. In keeping with our previous methodology the contents of the packages folder are checked in with the projects as this makes the packages locally available on the build box (no internet).
Building the solution on the build server is a different story, however, as I get multiple errors of the form...
..\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
This whole project.assets.json not found issue seems to be causing headaches all over. In my case the issue is that I'm trying to resolve it on our TFS 2017 Build Server, which does not and never will have internet access ('cos it's a server!).
All the solutions I've seen thus far seem to suggest running the Nuget Restore command but that can't work since the server cannot get to nuget.
This is nothing fancy yet, just a simple TFS 2017 Build definition with a Get sources and a Build solution step. I can't understand how something so simple has become so difficult.
Changing the Nuget Package Restore options makes no difference.
Since the project.assets.json files are generated on the fly in the obj folder, I can't even check them in to reuse. Can anyone please suggest a workaround, at the moment the test project is dead in the water.
Edit: trying the same process with a 4.6.1 web project created with VS2015 had similar results of unresolved references (e.g. System.Web) but didn't raise the same error, probably due to being an older, non-Core project.
According to I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
The issue seems not related to TFS build side since it also not work with local build through VS in the build agent machine.
Since this is a dotnet project. So, you could try to use “dotnet restore” and not “nuget restore”. Try using the dotnet core template (which uses dotnet restore).
If you are using authenticated nuget feeds, then you can use nuget restore but you also need to use nuget installer task. See https://github.com/Microsoft/vsts-tasks/issues/3762 for a discussion on that.
The Nuget version should be higher than 4.0.
Without dotnet restore and Nuget restore and only use get source/Visual Studio Build will not be able to build the dotnet core project. If your server do not have internet access, as a workaround you should use Local feeds.
I´ve tried to queue a new build on a new Agent, but it failed with this message:
Visual Studio version '15.0' not found. Looking for the latest
version.
I´ve already done these steps:
Remove and reinstall Visual Studio 2017 and Build Tools
Remove and create a new Agent (Downloaded here)
The thing is: On a different server, it works just fine with the same settings (but that´s not the answer...). So I have one definition on the same TFS but different Build Server. On both servers are Visual Studio 2017, Buildtools and an Agent installed.
Is there anywhere a setting I´ve missed?
First suggest you to manually run the build on the build agent server with VS. This will narrow if the issue is related to your build agent environment or TFS server side.
If it works on a different build server with the same build definition. Highly doubt it's related to your environment on the specific build sever, double check it.
If you are not working on the latest TFS 2017 update 2 version, you could also upgrade your TFS version, which may do the trick. Take a look at this similar question with same error: TFS 2017 - Build Server does not build Visual Studio 2017
In the build task make sure you've specified the correct MSBuild Version.
In some cases, specifying available MSBuild Version isn't enough, in which case you can specify the location of the right version of MSBuild.exe manually.
I'm hoping to get some assistance from you smart people!
I had my CI tool, TeamCity, compile solutions without a problem when VS 2015 was installed however I read from multiple sources that TeamCity does not need VS
Subsequently, I created an EC2 instance and installed JDK, MS BuildTools 2015, the Build Agent, and PsExec on my Build Server and connected it to the EC2 server housing the TeamCity client.
Unfortunately, it is giving off errors for a simple solution. -- http://imgur.com/M8sdDRs
I moved folders from my dev machine to the CI build agent server
Actually, you don't need to install Visual Studio 2010 or Visual Studio 2012 on your CI server. You only need to copy a few folders from a development machine to the same location on the CI server.
• C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web
• C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications
The problem is still persisting and I've come to a stand-still and frustrated with the problem.
THANKS SO MUCH!
If you're using the Visual Studio (sln) step runner type then you will need VS installed because that requires devenv.exe to build the solution. Unless you've got specific requirements for that, you should probably switch to using MSBuild as your build engine to remove the dependency on devenv.exe. Configure a build step of type MSBuild, point it at your solution and select Microsoft Build Tools 2015 / 14.0.
I doubt all your problems magically go away though, as you'll still need to stage bits of MSBuild like you've mentioned (WebApplications targets etc). I've had major hassles over the years trying to get a stateless, dependency 'free' agent build configured; Windows / .NET SDK is a can of worms.
Recommendation from TeamCity - Install VS on the CI Server to minimize the potential for errors. I installed the full Community Version, though VS Isolated Shell was fine as well, I wanted to minimize the room for error.
I ensured that: Administration > [Project] > Build Configuration Settings > Agents Requirements had MSBuildTools14.0_x86_Path existing and set my parameters to follow the following great resource - http://blog.anthonybaker.me/2013/04/how-to-automate-builds-with-teamcity_3119.html
We are in the process of upgrading our TFS 2013 server to TFS 2015. In that regard I have run into an issue when trying to perform an application build on a build agent with the new version, using our XAML template build script (which was created in TFS 2013).
Most of our solutions use the above-mentioned template when we build them. The solutions (sadly, still) use setup projects (.vdproj) to generate an MSI package for the application. To build the setup project, and produce an MSI, for a given application; we call the devenv.exe (in our case, it points to Visual Studio 2013) in our template build script:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe /Build "Release|Any CPU" "d:\<path_to_solution>\solution.sln" /Out c:\temp\out.log
However, on our new build agent no MSI is produced, and calling devenv.exe yields neither any output, nor any error messages. If I try to call devenv.com, however, it starts building, but still no MSI is being produced.
When things start to build using devenv.com It seems like it is completely disregarding the setup project (I have checked the build configurations, and the setup project is checked for build on the "Release|Any CPU" configuration).
I have looked at build logs, build process activity logs, and I have also tried to perform the steps manually on the build agent, but I haven't been able to find anything that could point me in the direction as to what might be causing the issue.
Does anyone have an idea what could be the reason for this? Could it be an issue with TFS Build 2015? The only difference between the old setup, and the new - as far as I can tell - is the following:
VS 2013 was installed on C: rather than D: on the new build agent, i.e. the path to devenv would be different, but that should not matter as long as the build script is looking in the right place, and finds it...
We use a different drop location than what we used for the old setup
Appreciate any help and suggestions I can get.
Problem solved, and everything is now building successfully. I did not do a good enough job of looking at the diff between the setup we had on the build agent we used for TFS Build 2013 vs. the one we set up for TFS Build 2015.
Firstly, to be able to build setup projects in VS 2013, one needs to install the Visual Studio 2013 Installer Projects extension on the build agent.
However, there are some bugs with this extension that often causes building setup projects to yield the following error message: "An error occurred while validating. HRESULT = '8000000A'". This error can be fixed by modifying the registry, as described in this SO post.
Building the setup projects using devenv.exe, however, still doesn't work. I have not been able to figure out why, yet.
Use the Vnext build in TFS 2015 to build .vdproj. You just need to add one additional build step i.e "command line" then call devenv.com to build.
Such that,
tool :
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.com
arguments :
HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj /build release
This will help you.
I have the following error on the build server for code that compiles and passes tests fine locally.
(150): 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.
I've added the WebApplications folder from my local machine to the appropriate path on the build server but I'm still getting the same error on build.
I believe the recommended approach with TFS2008 was to install VS2008 in it's entirety on the build server. Is this still the case with TFS2010 and VS2010 accordingly? a.k.a Sledgehammer to crack a nut.
Pretty much, especially if you plan on using other features like MSTest. You can try just adding the targets file but you'll probably still have some missing dependencies. You could go through the whole process of fixing the dependencies as you go along but it's probably easier just to install VS 2010 and be done with it.
This blog post seems to describe a way to do what you want without having to install additional software on the build server, if all you need is the .net compilers. It does not cover C++ compiler setup.
I discovered that if you're going to do just "standard" (i realize that's open to interpretation) web apps and non-web apps (e.g. services), you can get away with installing just Visual Studio 2010 Shell, plus Visual Studio 2010 SP1 on the build server. That will get you the missing .targets files.
Since a full VS install is required for advanced features, does anyone know if the build-server-install license cost is waived?