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.
Related
I think I have various beads on why this may be happening, but I can't quite put all the clues together.
We were building an ASP.NET app in VS 2019 with a nuget dependency (Microsoft.Data.SqlClient.SNI.1.0.19235.1 if it matters). I've used msbuild -t:package and in VS 2019, it would spit out bin\x86 and bin\x64 folders with the DLL from that nuget package. That package step would spit out a zip file and opening that up you can see the x86/x64 folders in there.
We upgraded to VS 2022 and the CPU arch folders are no longer there. I can see them get created in the working directory, but not in the package output.
Nothing in the project has changed. It's set to target "AnyCPU" and Framework 4.6.2. The command we're using to build hasn't changed either. As far as I can tell, it's just the upgrade to VS 2022.
I know VS 2022 is now 64-bit native, so I have a suspicion that's in play here. Any ideas on why those CPU-architecture folders are no longer included in the zip package? And how to get them back in there?
Thanks!
According to your description I make some test, hope it can help you:
Check your Configuration Manager under Build in the menu and add new Platform you need.
Build the project in Batch Build under Build in the menu.
We can see that .dll files are created in the same path so it will be covered.
Open the project file.(Right click on the project and Unload Project then right click again an choose edit project file)
You can see code like this:
Change the OutputPath to “bin\x64\Debug\”, ”bin\x64\Release\” and so on.
Reload the project and rebuild the project in Batch Build.
About how to Pack multiple platforms into one package you can see this(Pack multiple platforms into one package, using dotnet pack ).
If it helps anyone, since my problem was specifically with the SNI.dll not being emitted in the x64/x86 folders, my workaround solution was to upgrade the Microsoft.Data.* libraries to a newer version. The x64/x86 folders are still not emitted, but I now see Microsoft.Data.SqlClient.SNI.x64.dll and Microsoft.Data.SqlClient.SNI.x86.dll files in the root bin folder.
It doesn't answer the original question, but at least it got me moving.
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 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.
Intro
I don't know if this is a bug or there is something I'm completely missing.
I have a Project (Windows Service), let's called it WINSERV. And I have 3 DLL's which it depends which come from 3 seperate Projects (Project A, B, C). However A has a dependency on C. And B has a dependency on A and C.
When Building Installer with InstallShield LE, for some reason my Project C is always a STALE version which I cannot get to change. I increment the version, "make clean && rebuild", and the installation (on a remote server) always includes the STALE version.
I set each project that has a dependency on C, to not "Copy to Local", so allowing Project WinServ to maintain the "reference" itself, and copy it across for the Installer.
Problem
But again, no matter what I do, when I install it's the stale version. After a few hours, I did manage to get around the problem, by removing "Copy to Local" on Project WINSERV, and adding in Project C as an addition to Application Data (Project C's Primary Output) to the InstallShield Install Project. This seems to work!!!!
Question
I did try "MAKE CLEAN" a thousand times. I checked Project C DLL version before building and creating the Installer and it was always STALE, old version.
Anyone can explain this? or Bug?
PS. InstallShield LE does not do Windows Services so if you reading this, don't get caught out.
It's definitely a bug in Visual Studio 2012.
I've managed to replicate in the following fashion:
While having a Project opened (referencing let's say MYSQL 5.1.4).
I then commence to uninstall the MySQL Connector and install 5.1.7.
I close Visual Studio 2012 and recompile and all works well.
However when I build with InstallShield it still references 5.1.4 despite it being uninstalled. My thoughts is that it's caching it somewhere and accessing it later during the build process.
How I solved it, is after installing a newer/older/different version of an existing DLL, I then REBOOT my machine and all is now well.
Hope this helps someone
Sounds like a similar problem I had.
For some reason InstallShield sometimes gets DLLs from the temporary ASP.NET folder (even if your project is not ASP)
Try clearing the folder: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files