I've just recently started using a newly installed PC but am having trouble building a solution in Visual Studio 2022 that uses PostSharp (version 6.10.5). It works without problem to build the same solution on my old computer and strangely enough a colleague of mine who also recently installed a new computer has no problem building the solution.
Visual Studio throws a bunch of NU1101- and NU1102-errors such as these:
It also hints to the following information regarding PostSharp which I'm not sure how to fix?
The process "C:\Program Files\dotnet\dotnet.exe" failed with exit code 1.
Restore of compiler dependencies failed. To disable compiler dependencies restore use PostSharpDependencyRestoreDisabled=True MSBuild property.
Unable to start PostSharp due to previous error encountered while creating fallback package directory.
We're including PostSharp via a private Nuget package where we're referencing PostSharp like this after input in this thread: How to have PostSharp included in build process for ASP.NET WebApi project when installed using our own Nuget package?.
<PackageReference Include="PostSharp" Version="6.10.5" PrivateAssets="none" />
If I exclude everything related to PostSharp, the solution builds just fine but not with PostSharp included. Any help here would be very much appreciated.
/Martin
If NuGet errors are in the build output and immediately before the error stating that PostSharp's dependency restore had failed (not apparent from screenshots), PostSharp is attempting to gather its references for the first build on the machine.
PostSharp does this by running NuGet restore under current settings for packages it depends on (e.g. System.Runtime.CompilerServices.Unsafe).
Since NuGet sources that are enabled for the build seem to include only "Offline packages", it is not able to find required packages as these are not present on your machine.
The solution is to run the build once with NuGet.Org package source enabled. PostSharp should then be able to download its dependencies and all subsequent builds should run without problems (unless you upgrade to a new minor version of PostSharp). The presence of NuGet.org package source is probably the difference between machines that causes this problem.
As mentioned in my comment to the answer above the solution to my problem was to:
Remove our own nuget.config file (even if it contained a reference to the nuget.org package source)
Add a reference to the nuget.org package source (https://api.nuget.org/v3/index.json) in Visual Studio under Tools --> Nuget Package Manager --> Package Manager Settings --> Package Sources
Build the solution again
Add our own nuget.config file to the solution again
Related
We have a number of .NET Framework projects with a "nuget pack MyProject.csproj" command in the post-build step. We have been using VS2010 (:O I know) until now, and it has been happily spitting out nupkg files.
We recently updated our build tools to the 2019 version (running the new version of varsall.bat before calling msbuild), and the "nuget pack" command now fails:
Error NU5012: Unable to find 'MyProject.dll'. Make sure the project has been built.
What I've tried:
Adding a "nuget spec" step before packing
Upgrading the nuget CLI executable to the latest version
Updating from packages.config to PackageReferences
This allows you to use MSBuild -t:pack. However, two issues:
When running this in the post-build step on my machine, it starts dozens of cmd & MSBuild processes and pegs my CPU.
Our developers are stuck on VS2017 for now, but the 2017 build tools are no longer available for our build server (so we use 2019). The 2017 & 2019 installs put MSBuild in different locations. We could set path variables for all the machines, but that seems brittle.
I'm playing with upgrading one of the projects to the new csproj format, but it is rather involved. Upgrading all of our projects will be an effort all its own, and I'm still exploring the ramifications.
Is there something simple I'm missing which will allow this to work without large modifications?
Error NU5012: Unable to find 'MyProject.dll'. Make sure the project
has been built.
This message indicates that the nuget.exe can't find the output assembly. So you must make sure the assembly is created successfully.
And one point you need to take care, normally we use command like nuget pack foo.csproj -Properties Configuration=Release to pack the assembly built in release mode. If you use command like nuget pack xx.csproj in post-build-event, no matter which configuration you use msbuild to build the project, nuget will always try to find the assembly in ProjectDir/bin/debug.
So when you deploy the project to remote server without bin and obj folders, if you try to use command like msbuild xx.csproj /p:Configuration=Release, the build is in release mode while nuget.exe will search the bin\debug instead of expected bin\release. You should check if you're in same situation.
Why does NuGet pack break with VS2019 build tools?
This issue is not about the build tools package. Since the error message you got came from nuget. Msbuild just help call the nuget.exe, and the cause of the issue is nuget.exe can't find the needed assembly by one specific path. Please check if the path in the error message is right, and then check if the assembly is in that path.
I also ran into the same issue during our TFS upgrade to Azure Devops. The new Nuget task doesn't have the switch for -Build. The fields in the Nuget task screen for Pack also doesn't allow you to add this switch, that's why it's complaining about not finding the dll or the output of the build. I modified the nugetpack.js file on the agent's task folder to test the theory and now the pack options build successfully.
This is the line I added to the js file (towards the bottom of the page):
nugetTool.arg("-Build");
what would be nice is to have this option represented as check box to cover if there is use case to call Nuget pack without -Build switch
I have the same problem as described here:
https://github.com/NLua/NLua/issues/33
Though I have followed the instructions to create a console application...
http://www.screencast.com/t/M12TqePQxW
...which works just fine, when I create a library project and reference it from another project (in this case, a Web API project) the following error occurs:
Unable to load DLL 'lua52': The specified module could not be found.
At this line:
using (var lua = new Lua())
How can a library project be made with the NLua nuget package without failing?
It is the exact same issue as described in the GitHub issue, the Nuget package is missing two DLLs that you need to use lua52.dll. One small difference, the current package (version 1.3.2.1) includes a newer version of lua52.dll that was built with VS2013. And therefore has a dependency on msvcr120.dll and msvp120.dll.
Beware that this may change in the future when Nuget updates your project.
As-is, you need to download and install the Visual C++ redistributable package for VS2013. Run both vcredist_x64.exe and vcredist_x86.exe so your project can run either in 32-bit or 64-bit mode.
To avoid having to do this on the machine on which you want to deploy your program, I recommend you copy the two DLLs from the c:\windows\system32 (64-bit) or c:\windows\syswow64 (32-bit) directories into the same directory as your EXE.
The package author could have done a better job putting this package together. Short from including the DLLs in the package, the better solution would be for him to rebuild lua52.dll with the /MT option so these dependencies are linked in. Consider clicking the New Issue button to let him know.
I am trying to setup a CI build using Visual Studio Online but I am getting the following error about the NuGet client:
The 'System.Net.Http 4.0.0' package requires NuGet client version '3.0' or above, but the current NuGet version is '2.8.60318.667'.
Solution builds and deploys fine directly from my Visual Studio 2015 itself but I am unable to get it to build in VSO. Does anyone if NuGet 3.x is installed on hosted build controllers or if I can supply my own copy along with my solution?
It's hard to guess by the question what build tasks are used. If you use VSBuild/MSBuild, it is only possible to turn "Restore NuGet packages" on, but there's no influence on the NuGet version.
However, if you turn this checkbox off, and instead add another build task called NuGet Installer before the main build step, you'll be able to provide a custom path to NuGet.exe. In the case of hosted build agent, the most obvious option is to commit required version of NuGet.exe to the repo, and then reference it from the build step:
Sounds like a hack, but it might work in your case.
Thought I would try and get the most out of my visualstudio.com trial membership. I created a solution with a few projects, pushed it to the Microsoft git source control provider, configured a build definition and tried to build it on the project server. However it keeps failing telling me:
The type or namespace name 'Moq' could not be found (are you
missing a using directive or an assembly reference?)
I know this means that the build server can't find the Moq.dll library. I had installed it using NuGet, but configured my .gitignore to keep the packages folder out of source control. I also enabled NuGet package restore for the solution and pushed nuget.exe, nuget.targets, and nuget.config (all 3 of the files in the .nuget folder) along with all of the other project files.
Now I am sure I could get the build to work if I pushed the packages folder too, but I want to keep the nuget packages folder out of source control. So I am wondering, is this possible? The visualstudio.com docs say that the build servers have visual studio 2013 installed, and because of this I assume that nuget package restore would work to download the missing dll's so that they can be resolved by MSBuild. Is this right? Or to use automated CI builds at visualstudio.com, do you need to have your packages under source control?
According to the log file, nuget package restore downloaded the package. What gives?
Project "C:\a\src\MySln.sln" (1) is building
"C:\a\src\Tests\MySln.ProjA.UnitTests\MySln.ProjA.UnitTests.csproj"
(3) on node 1 (default targets). RestorePackages:
"C:\a\src.nuget\NuGet.exe" install
"C:\a\src\Tests\MySln.ProjA.UnitTests\packages.config" -source ""
-NonInteractive -RequireConsent -solutionDir "C:\a\src\ " Restoring NuGet packages... To prevent NuGet from downloading packages during
build, open the Visual Studio Options dialog, click on the Package
Manager node and uncheck 'Allow NuGet to download missing packages'.
All packages listed in packages.config are already installed.
PrepareForBuild: Creating directory "obj\Debug\".
ResolveAssemblyReferences: Primary reference "Moq". C:\Program Files
(x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1635,5):
warning MSB3245: Could not resolve this reference. Could not locate
the assembly "Moq". Check to make sure the assembly exists on disk. If
this reference is required by your code, you may get compilation
errors.
[C:\a\src\Tests\MySln.ProjA.UnitTests\MySln.ProjA.UnitTests.csproj]
This line is also in the build log file, below the above:
Considered "..\packages\Moq.4.1.1311.0615\lib\net40\Moq.dll", but it didn't exist.
I had this same error but it was occurring on our build server. I had added Moq via NuGet, checked in the project and everything was fine. I then moved the project into a new folder in TFS and the build server just couldn't seem to find Moq. It was building great locally. I ended up fixing the problem by making sure all of my changes were checked into source control and then deleting my local source code directory. I got latest and my test project realized it needed a new copy of Moq. I blame TFS/ source safe or what ever the Visual Studio integration module is for not adding it to source control at some point in time.
Figured this one out on my own. Turns out I had added the nuget packages before moving the test project into a Tests subfolder. The solution still built on my LM, probably because the dependencies were already copied to bin/Debug. After reinstalling the nuget packages, the solution built on vs.com.
I’ve installed PostSharp on my machine, added PostSharp.dll to my dependencies folder and built my aspect attribute, which is works correctly.
Now I am going to check-in my changes.
What would happen on build machine or my colleague's computers, when they would get the latest code but wouldn't have installed PostSharp.
Will the attributes just ignored?
Or some errors during build or run-time would happen?
If PostSharp is installed on other development machines, you have also to install it on build servers.
See also http://doc.sharpcrafters.com/postsharp-2.1/Content.aspx/PostSharp-2.1.chm/html/522bb950-5fdf-4601-b75e-7c60c8b3ae08.htm.
I think it errors out if you try and build it on a build server without it installed, even with the dll added.
As of 2.1, the build server must have PostSharp installed as well as any developers who need to build the projects. If you don't then the build will fail and they will probably not behappy with you. PostSharp is part of the build process which is why it's needed on the build server.
You cannot have PostSharp ignored. If the other devs are able to reference PostSharp.dll to satisfy the types and it actually built then they would have invalid output because it doesn't have the aspects applied in the final assemblies.
I recommend installing PostSharp into the source repository (http://doc.sharpcrafters.com/postsharp-2.1/Content.aspx/PostSharp-2.1.chm/html/41129237-a5d4-4acf-aef4-c46759ccfb4b.htm) to make it easier on everyone.
I can confirm that a project with aspect attributes can be compiled without any errors on machine without PostSharp installed.I assume that PostSharp DLLs are added as dependencies.
Of course, there will be no post-build processing and all attributes will be ignored, but not related to PostSharp functionality will work as expected.
Clarification 12 Jan 2013:
Other developers and build server were able to ignore PostSharp when I used Setup Program for installation (as described in
http://doc.sharpcrafters.com/postsharp-2.1/Default.aspx##PostSharp-2.1.chm/html/f7b57aa1-369a-406a-8863-8b6865265a21.htm
) on my machine only.
However when using NuGet installation in packages subfolder of installation (currently recommended by PostSharp author ) all developers are forced to install Starter or trial professional edition
You can disable PostSharp for some configurations.
Project > Setting > PostSharp
Choose Yes for Disable PostSharp for this configuration
I responded to similar question here :
Disable Postsharp in debug builds