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.
Related
Environment
Visual Studio 2019 (latest SP upto Dec 2020)
.NET Core 3.1 with latest SP up to Dec 2020
WebAPI project with lots of child DLLs being loaded at runtime
Problem Context
When the solution is build, a "GenerateDepsFile:" error is given by MS Build for a particular project in the solution. It tries to add an item to a dictionary when it already exists, but not which dictionary it is trying or what duplicate key is being attempted.
Exploration Performed
There are no compilation errors (apart from Deps file)
All referenced projects are building fine with no errors in themselves
All NuGet references are available with no errors
Clean and Rebuild all solutions involved
Manually delete the objand bin folders across codebase
The "GenerateDepsFile" task failed unexpectedly is too large and you should check its detailed build log to judge what is the real problem.
Under Tools-->Options-->Projects and Solutions-->Build and Run--> set MSBuild project build output verbosity to Detailed and then build again to get its detailed log.
Also, you can share the detailed error build log here with us.
Maybe you could check these suggestions:
1) clean nuget caches or just delete all cache file under C:\Users\xxx\.nuget\packages.
2) do not forget to delete .vs hidden folder under the solution folder, bin, obj folder of the project, and then use dotnet restore command or msbuild -t:restore command to restore these files.
3) update VS2019 to the latest 16.8.4 and your Net Core 3.1 Sdk to the latest 3.1.11.
After lots of exploration, it looked like a multi version NuGet package scenario (cleaned the NuGet cache already)
Finally I went to all child projects and validated if the same version of all NuGet package is being used across. It turned out that the version of some assemblies ( esp Microsoft.Data.SqlClient) were different in child projects and the calling project.
Since the projects themselves were building all fine, this was not reported on project level, but when those DLLs were getting consumed in parent one, it start giving the error.
It turned out the child projects were built a while back with the latest version available at that time. The parent project was just referencing the DLLs from the output folder and was not aware of previous version and got its own version updated..
So, do ensure that when a particular version of NuGet is approved at one place, that gets updated across the whole eco-system!
However MS should update the error to at least point what dictionary is failing with what specific key in the main message as its very hard to debug with the verbose log.
The "GenerateDepsFile" task failed unexpectedly.
I believe You just need to delete the bin and obj folder and then Clean and Rebuild solution.
this should work, It work for me after going through many approaches.
Me - Front End web developer with an ok working knowledge of writing VB.NET code but I have never built a .NET project from scratch using Visual Studio.
External developer - Experienced VB.NET developer but completely new to version control and TFS. Also extremely cheap and prone to infuriatingly poor programming practices. He does things that make you bang your head on the table.
Background
Our external developer has coded our site but over the last few years I have been tweaking aspects of pages and have managed to learn quite a bit of VB.NET along the way. He has never used source control and I don't think he's ever had to work with another developer before.
Up until now he has maintained a local copy of the website. He makes changes to this local copy and when he wants us to test it he uploads the relevant files to our dev server. I have no experience of Visual Studio projects/solutions so if I have made tweaks to things I have edited the aspx/asxh/config files in my preferred editor and then uploaded them to the dev server. If everything works correctly I ask him to download them from the server so he can update his local copy.
I have been maintaining a local git repository of the website for the last 2 years. If he makes a change I check it in.
Obviously this is a nightmare to work with so we have now insisted that he starts using version control. I recommended GIT but he has decided to use TFS.
He has now put his solution and all the files into TFS. I have installed Visual Studio 2015 and successfully connected to TFS. I have mapped the files from source control to my own workspace but I am now at a loss as to what to do next.
Questions
As soon as I open the .sln file he has uploaded it says I have checked out the file and made changes. When I check the diff it seems to be because I am using a newer version of Visual Studio than he is. Does the .sln file need to be in version control? Or are we suppose to maintain our own versions of the .sln file and simply check in everything else?
If I try and build the project it fails because the web.config is set up for his machine and not mine. How can we maintain 3 versions of the web.config file? One for my local, one for his, and one for our dev/live environments?
I am not convinced he will have added the project to TFS correctly because he's never used it before. This is basically the blind leading the blind.
Question 1:
You need to put the .sln file in version control. Before check out the .sln file, please do a "get latest" step, which will make sure both of you are working on the latest version. When you try to check your local version in the server, and he had uploaded his local version in the server. You may have to solve conflicts before the check in.
Question 2:
You should build your project and published the website on the server. The build agent will only maintain one version of the web.config file. If he has built the project with his web.config. And you want to build the project again with your web.config, the build agent will delete the previous web.config and pull down your version. Then build the project with your's web.config.
Moreover, if both of you are not similar with TFS. Suggest you taking a look at below MSDN link which related to source control and build.
Use Team Foundation Version Control
TFS Vnext Build
I have been trying to find an "elegant" way to integrate non-NuGet package with my Bamboo builds.
There's a plethora of stacks on the topic of adding non-NuGet packages into NuGet bundles:
managing non-nuget dlls along with nuget packages
Creating NuGet package with reference to a non-NuGet reference
Trying to add non-.NET libraries to NuGet package
and the list goes on. There's also many a stack about using NuGet in Bamboo and that part works smoothly.
None of these deal with the situation of having an automated build environment, which may be sitting on some other remote server, running Bamboo.
Specifically, I'm trying to automate Xamarin.iOS deployments to HockeyApp.
The steps are:
Coding and local testing in VS2015 on Windows and with Mac for iPhoneSimulator
Merge into deployment branch and push to Bitbucket server
Bamboo picks up the push and kicks off build
Build checks out deployment branch
Runs NuGet downloads
Starts compile for Ad-Hoc/iPhone environment, creating IPA
Kicks off the HockeyApp deployment (there's a free addon for that)
Nearly all the steps are in place, except for the one where I have 2 dependencies which the commercial vendor (Syncfusion) has for unknown reasons decided to bundle into their "Studio" product, from where my Visual Studio project/solution has to refer to them by location outside of my project directory.
As a result, my Bamboo build fails with not-found DLLs, because they're missing as they would have to come in somewhere between 5. and 6. above.
I don't want to copy the binaries and then check/commit/push them into my repository, as that's considered a Bad Thing. My Bamboo Plan already successfully grabs NuGet packages before the actual build without having to drag binaries along.
Simply copying the DLLs on to the Bamboo build machine (i.e. where the remote agent is running) was one idea, but the problem is that the VS/MSBuild project file now has hard-wired directories - so, I'd have to install the whole Syncfusion Studio, or emulate their directory structure just for those 2 DLLs.
So I would need to adjust the .csproj references in an automated fashion. Not sure how I would do that, except with Yet Another Task and Script.
Apart from yelling at Syncfusion (which I've already done) about making all their DLLs available through NuGet (because some are, and those I'm successfully receiving in step 5. above), does anybody have a suggestion how to get this missing step to work?
For expediency sake, I have now added the libraries to the repository in a separate sub-directory.
It's not how I wanted to do it, but as the 2 libraries were a mere 200-300KB each and as there just didn't seem to be a simpler solution it solved the issue for now.
Specifically:
Leave .dll in .gitignore
Copy libraries you need into local sub-directory, e.g. LocalLibs/
add specific libraries with git add -f LocalLibs/speciallib.dll so that only these become a part of the repo
Change the project reference in Visual Studio to point to the local libraries, instead of their main install location
Verify that builds still work from within Visual Studio but also with MSBuild
I may revisit this and update if a better way comes along, especially if the libraries are significantly larger, such that you definitely would not want to add them to your repository.
We have a solution which contains several projects. Some projects have NuGet packages installed, for example Json.NET. The whole solution is checked in to TFS Version Control, without the packages folder. We have set up Automatic Package Restore according to the "Nuget 2.7+ method" as described in the Nuget documentation (actually we didn't set up that much since all this is enabled by default).
When we build this solution on another computer, all packages are getting restored.
When we build this solution on our TFS 2013 Build server, all packages are also getting restored.
Now here comes the problem:
When we create a build on our TFS 2013 Build Server which should build only one of the projects in the solution (so targeting the .csproj file instead of the .sln file) the nuget packages are NOT getting restored!
Can anyone tell me why this is happening, or tell me if this is by design? I really don't want to build the whole solution, since it is a release build for only a single small project, but i do want the packages getting restored automaticly...
I believe the Automatic Package Restore hooks into the Build Solution event. Since there's no solution, it's not triggering the restore.
To build a single project, you may need to create a new solution that references just that project.
I use Visual Studio 2013, and am building on TFS 2012 (update 3). I have a relatively small project that builds fine locally as well as on other machines on which I simply get the latest version from source control. When I build on the build server however I get several of the following errors:
The type or namespace name 'xxx' does not exist in the namespace 'yyy' (are you missing an assembly reference?)
Several of these errors are thrown for different namespaces, including Entity and other NuGet packages.
At first I thought that the build server was not restoring the NuGet packages, but after some investigation it seems that the packages are in fact downloaded onto the build server.
I have set up automatic package restore in VS and added the system environmental variable "EnableNuGetPackageRestore = true". To double check, I manually executed the following restore command on the server:
nuget.exe restore fullpath_to_solution\solution_name.sln
and the output was:
All Packages listed in packages.config are already installed
Then I thought that since TFS is older (2012) than VS (2013), perhaps I need to install .Net 4.5.1. But as it turned out, .Net 4.5.1 was already installed on the build server.
Any suggestions on how to get this project to build on the server?
Could be many issues, possibly proxy.
Log on to build server with build account.
Try building the solution in VS.
See if packages are restored on build.
You should then be able to trace the issue.
The best idea is to delete the contents in your workspace, then build to make sure all packages are restored properly before checking in