I get the following error when trying to perform a NuGet pack.
The imported project "C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\WCF\Microsoft.VisualStudio.ServiceModel.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
C:\Projects\MyProject.csproj
I am trying to perform the pack in my PostBuild event with the following command:
nuget pack "C:\Projects\MyProject.csproj" -Properties
Configuration=Release -IncludeReferencedProjects -OutputDirectory
..\..\
I also tried to perform the pack from the command line and got the same error.
I am using NuGet 2.5.XXX. I am using Visual Studio 2015 SP3. My project is a WCF Service Library. I use the Post Build command in many other projects with no problem. Also, I have created other WCF services with no problem.
I suppose I should upgrade NuGet, but am slightly afraid it may break something else.
You can upgrade the nuget. That will upgrade all the references that you were using that will not break any of your functionalities.
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
Is it possible to create a nuget package containing a custom build step (analyzing the generated assembly and automatically generating some metadata)? The target environment should be .NET Core with the new .csproj format (Currently using Visual Studio 2017 RC). Best case would be if this only adds a msbuild step and no dependency to the projects resulting assembly.
If seen that it should be possible with full .NET, but the documentation for msbuild and the new .csproj for .NET Core is a bit sparse at the moment.
You can add MSBuild targets to a NuGet package in the "build" folder. The targets or props file name must match the package ID. When installed via "PackageReference" or packages.config, NuGet will automatically import the targets/props file into the csproj, so these files must be written as valid MSBuild code.
i.e. if your package was named "MyClassLibrary", you could have the following layout:
(package root)
lib/
netstandard1.3/
MyClassLibrary.dll
build/
netstandard1.3/
MyClassLibrary.props
MyClassLibrary.targets
For example, see Microsoft.Extensions.Configuration.UserSecrets on NuGet.org or and its source code on GitHub. This package uses an MSBuild target to automatically generate an assembly attribute before the compilation step
Nuget may execute "init.ps1" powershell script during installation if find it in your nuget package. But keep attention, that script support was modified in Nuget 3.x:
In Nuget 3.xx Powershell script support was modified to no longer execute install and uninstall scripts (install.ps1, uninstall.ps1), but init scripts are still executed.
Additionally, running NuGet outside of Visual Studio at the command-line or on other operating systems cannot execute these Powershell scripts as they relied on Visual Studio automation. Powershell is in NuGet to provide a shim to allow for missing features to run inside of Visual Studio
Powershell script support was modified to no longer execute install and uninstall scripts, but init scripts are still executed.
You can find more here in "Powershell Install and Uninstall Scripts".
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.
I have a Visual Studio project, that's set up in TeamCity with a build-task to create artifacts via OctoPack (3.0.43). Next, a deploy-task, that receives the output NuGet-package from the build-task task (on successful build) as a dependency.
I've tried setting up the build-task using both the MsBuild build-runner and the Visual Studio (sln) one, but in both cases no artifacts are created.
I've added the OctoPack NuGet package to my Visual Studio project.
Found this one out myself:
When I added OctoPack NuGet package, all seemed well. Hinted by various posts, I looked to the OctoPack.targets file. Here I stumbled upon the Install.ps1 file, that seemed to be supposed to inject some build-actions in the VS project's .csproj file upon adding the NuGet package to project.
Next up, I removed the NuGet package and tried re-installing, but this time using the Package Management Console (View > Other Windows > Package Management Console) with command:
Install-Package OctoPack
This output the following:
Successfully added 'OctoPack 3.0.43' to MySolution.MyProject. & :
File
C:\somepath\mysolution\packages\OctoPack.3.0.43\tools\Install.ps1
cannot be loaded because running scripts is disabled on this system.
For more information, see about_Execution_Policies at
http://go.microsoft.com/fwlink/?LinkID=135170. At line:1 char:3
So, some security stuff was preventing the PowerShell script to do its stuff with the .csproj file.
Solution:
In the same window (Package Management Console) or in an elevated PowerShell, execute
Set-ExecutionPolicy RemoteSigned
Retry NuGet package-installation (still same window or using the NuGet GUI) - now the NuGet package installer should inject whatever your version of OctoPack wants it to. After this, my TeamCity build started generating OctoPack artifacts correctly.
I am getting this error on my CI server:
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\WCF\Microsoft.VisualStudio.ServiceModel.targets" was not found
It seems my WCF service library project references that file, but the VisualStudio folder on Program Files\MSBuild\Microsoft doesn't contain a WCF folder.
I guess I need to install something on the server.
What do I need to install?
Well this ruined my morning, but let's not allow it to ruin anyone else's. I couldn't find this information anywhere else. You need to copy a few files from a development machine with VS Pro 2012.
As aphexddb mentions, you need to copy some targets from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\WCF to the same location on your CI server.
This then references an assembly called Microsoft.VisualStudio.ServiceModel.Core. You can find this assembly in either the GAC or in the IDE directory at C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE.
Copy this to your CI server and execute gacutil.exe -i Microsoft.VisualStudio.ServiceModel.Core.dll
This was enough to fix it for me.
This isn't the first time I found targets missing from my VS express install in my CI server. I can't help but feel that there is some sort of package I can download from somewhere that fills all this in. Does anyone know of such a thing? If not, perhaps we should create one.
Can still happen on vs2019
error MSB4019: The imported project "C:\Program Files (x86)\Microsoft
Visual
Studio\2019\Professional\MSBuild\Microsoft\VisualStudio\v16.0\WCF\Microsoft.VisualStudio.ServiceModel.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
WCF is not installed by default as part of 'ASP.NET and web development' workload. To fix this,
On visual studio installer > modify > individual components tab, search for wcf, check, modify - the .targets file gets now installed, msbuild builds ok.
MSBuild auto-detection: using msbuild version '16.3.2.50909' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\bin'
I ran into this with Visual Studio 2017, for me the resolution was to modify my installation of Visual Studio to include the Windows Communication Foundation components.
Extract this file into folder
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\WCF
The file name is "Microsoft.VisualStudio.ServiceModel.targets"
Now you can solve the problem using the Nuget Package MSBuild.Microsoft.VisualStudio.Web.targets
so the build process does not require any change to the build server.
Install-Package MSBuild.Microsoft.VisualStudio.Web.targets
Details:
remove the element for "ServiceModels.targets" in the .csproj file
remove the target WebApplication from the build command (in yaml)
Ran into this same issue. Did the following to resolve:
Installed the Microsoft Web Platform Installer
Copied Directory "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\WCF" from dev laptop with Visual Studio 2012 to the build server
I've had the same error - my issue was that MS has modified the way MSBuild looks for the versions of VS in the build process template.
Make sure to use the right build process template.
If using TFS2013 and VS2013 use TfvcTemplate.12.xaml
I ran into this same error. In my case, the problem was that my Visual Studio 2008 project didn't get upgraded correctly, probably due to files being marked "read-only" by my source control. To fix it, I loaded the solution in Visual Studio 2015 with everything checked out.
The specific line in the .csproj file changed from
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\WCF\Microsoft.VisualStudio.ServiceModel.targets" />
To
<Import Project="$(WcfServiceModelTargetPath)\Microsoft.VisualStudio.ServiceModel.targets" />
If you are using VS 2022 build tools, it is no longer in the individual components section. It is on the first tab "Workloads", included in ".NET desktop build tools", you will see it in the list on the right-hand side when you select it.