I am using Visual Studio 2019 after upgrading from 2015. The problem I am having is when calling MSBuild from the command line, older projects which have a NuGet.exe within the .nuget folder inside the project/solution directory will fail to build because they've got an old version of the exe.
Can I delete the NuGet.exe from .nuget folders, remove references to it in the csproj files, and use one central NuGet.exe from this point on?
Is this the correct thing to do?
Yes, that .nuget\NuGet.targets and .nuget\NuGet.exe thing is from Visual Studio 2013 and earlier. Not only is it causing you problems now, but every build and restore from in Visual Studio 2015 and later has been slower because these projects are using this old "integration". (NuGet is probably restoring in VS, and then when the build happens, the restore via nuget.exe in NuGet.targets is running, doing a second restore check)
The NuGet team have some docs, with instructions in the "Migrate to automatic package restore (Visual Studio)" section: https://learn.microsoft.com/en-us/nuget/consume-packages/package-restore#migrate-to-automatic-package-restore-visual-studio
Related
I have a library that I can successfully build locally and on another computer. However, when I try to do the build at VSTS online, I get
classes.csproj(152,5): Error : This project references NuGet
package(s) that are missing on this computer. Use NuGet Package
Restore to download them. For more information, see
http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is
....\classes\packages\NuProj.0.11.30\build\NuProj.props
I have tried multiple times to check the git repository but comparison shows that the VSTS version is the same.
What am I missing? Do I need to delete this VSTS project and simply reload? Hoping not.
From the command line, you need to do a manual nuget restore before building your project. Visual studio can take care of this automatically. But from the command line, msbuild is not running visual studio.
Thus do something like
nuget restore c:\my\path\to\my\project.sln
Is the Host Controller on Visual Studio Online now automatically restoring NuGet package before calling MSBuild?
Previously I had to manually execute the following:
nuget.exe restore MySolution.sln
Now, when creating a new build in a new project, I noticed that I didn't need to do this. When looking at the build logs, I see this:
This was a change in TFS 2013 Update 2 and is reflected in VS, TFS, and VSO...
One of my projects is using Clarius Transformation nuget package to transform a .tt file during build without having to install VS Modeling SDK on each machine. However, in one of the solutions, it seems that it is not transforming the files and generates many errors.
How can I guarantee that this transformation is done?
UPDATE
I think the problem may be the fact that the nuget packages are not committed to source control. Then visual studio needs to download the package and only after this run the transformation. But this is just a shot in the dark.
I am not sure about your specific case, but it sounds like you have a post/pre-build action related to one of the projects which creates the files in a wrong order. Check if one of the custom build options has such actions and make sure it is in the correct position in the build order.
My guess is that you are using the older MSBuild based package restore which restores the NuGet package too late in the process for the custom MSBuild target in the NuGet package to be run.
The MSBuild based package restore, which is enabled when you right click the solution and select Enable NuGet Package Restore, adds a .nuget/NuGet.targets file to your project. If you use the MSBuild based package restore then the NuGet package is restored by MSBuild during the build. However the Clarius.TransformOnBuild NuGet package will be restored too late for MSBuild to be able to use the custom MSBuild Clarius.TransformOnBuild.targets and run the transforms.
If you do not use the MSBuild based package restore, and rely on the newer automatic package restore which is done by Visual Studio itself, then your text template should work. With the newer automatic package restore Visual Studio restores the packages when you start the build but before MSBuild is started. This means that any custom MSBuild targets are properly loaded by MSBuild and will be available for use. The newer automatic package restore was introduced to solve this problem.
From the NuGet site:
Packages are restored before MSBuild is invoked by Visual Studio. This allows packages that extend MSBuild though targets/props file imports to be restored before MSBuild starts, ensuring a successful build.
Testing this with Visual Studio 2013, with a text template and the Clarius.TransformOnBuild NuGet package installed, the automatic package restore allows the text template to run during the first build. With the MSBuild based package restore the text template is not run the first time but only on the second build after the NuGet packages have been restored.
So your options are:
Stop using the MSBuild based package restore.
Check your NuGet packages into source control.
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.
I have a CruiseControl .NET build server running on Windows Server 2003, and I am trying to build and publish my ClickOnce application using msbuild.
Everything is working fine, except when I enable the bootstrapper of my ClickOnce application. When this happens, I get the following error in the DeploymentGenerateBootstrapper target:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3939,9):
error MSB3147:
Could not find required file 'setup.bin' in 'E:\Projects\src\TestProject\Engine'.
.NET Framework 3.5 SP1 and 4 and latest Windows SDK for both are installed on the server, but the bootstrapper folder in C:\Program Files\Microsoft SDKs\Windows\versionNo\ does not exist. I tried copying the files from my workstation machine with no luck.
I do not want to install Visual Studio on server and only install the necessary SDKs.
I have also tried copying the bootsrapper folder from my machine
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper
to build server but no luck.
Any ideas?
You will also have to add the associated key and value to the registry to allow MSBuild to find the path to the Bootstrapper folder. I can confirm that this has worked for me using the following regedit.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\GenericBootstrapper\4.0]
#="0"
"Path"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\Bootstrapper\\"
Update: According to Emma's TFS Blog it appears the following registry values are checked in order to find the bootstrapper path and if not found looks in your local project folder under the Engine sub folder and then bails with the MSB3147 error if not found there.
HKLM\Software\Microsoft\GenericBootstrapper\<.NET Tools Version>\
HKLM \Software\Microsoft.NetFramework\SDKInstallRoot\Bootstrapper
HKLM \Software\Microsoft\VisualStudio\\InstallDir\Bootstrapper
Reminder: Also remember that there is a 32-bit and a 64-bit registry so be sure to add this value to the same registry that your tools will be accessing.
In the meantime I've also created a feature request to get a more reasonable solution for this issue. Please vote on my feature request to get Microsoft to take a look at it.
BTW, here are a few more links about this issue:
http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/7672078f-f2bd-4142-b8a9-740c2a8a5ae7
http://social.msdn.microsoft.com/Forums/en/msbuild/thread/6964ba78-5b66-4cd1-bdd1-b31edb76b96a
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/97ac8717-daf7-4554-8dfa-8a63da47a17d
MSBuild: error MSB3147: Could not find required file 'setup.bin'
https://connect.microsoft.com/VisualStudio/feedback/details/361924/remove-bootstrapper-from-microsoft-sdks-directory
http://blogs.msdn.com/b/emmamou/archive/2009/04/08/team-build-for-clickonce-application-with-bootstrapper.aspx?CommentPosted=true#commentmessage
You can also pass the location of the bootstrapper packages to the common Publish target like this:
<PropertyGroup>
<BootstrapperSdkPath>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper</BootstrapperSdkPath>
</PropertyGroup>
and then
<Target Name="Publish">
<MSBuild Targets="publish" ... Properties="GenerateBootstrapperSdkPath=$(BootstrapperSdkPath); ..."/>
</Target>
I struggled with the same problem on my win7 x64 machine. I have not installed Visual Studio and tried to build and publish a .NET 4.5 WPF solution. I had to add the following keys to the registry
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\11.0]
"Path"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v8.1A\\Bootstrapper\\"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\4.0]
"Path"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v8.1A\\Bootstrapper\\"
You also need to copy the Bootstrapper folders from your dev machine. This blogpost directed me in the right direction http://www.wiktorzychla.com/2013/11/msb3147-could-not-find-required-file-on.html
I had a similar issue to this but in my case I do have Visual Studio installed on the box, and publishing from Visual Studio works fine.
When publishing from the command line with msbuild.exe, the build failed with aforementioned error "MSB3147 Could not find required file 'setup.bin'".
The solution was to explicitly specify what version of Visual Studio to use during build.
<MSBuild
Projects="MyProject.csproj"
Targets="publish"
Properties="Configuration=Release;PublishUrl=C:\AnyFolder;VisualStudioVersion=12.0"/>
I have Visual Studio 2013 on a Win7 x64 machine. My reading of the problem is that MSBuild was looking in the wrong place in the registry. By explicitly telling MS Build to use VS 12.0, it picked the correct registry location entry and consequently the correct path to BootstrapperSdkPath.
I was able to fix this problem by pointing to MSBuild.exe from this location
C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe
Previously I was pointing to
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
Hi I know this answer its soooooo late but just in case
I had to add the Path prop to the task, with the Path where the bootstrapper its located, in my case I used Visual Studio 2015 so the Path is:
**Program Files(x86)\Microsoft Visual Studio 14.0\SDK\Boostrapper**
MSBuild has a Task GenerateBootstrapper in my case
<GenerateBootstrapper>
AplicationFile="$(AppName)"
ApplicationName=..
ApplicationUrl=..
BootstrapperItems=..
Culture=..
ApplicationUrl=..
Path="Program Files(x86)\Microsoft Visual Studio 14.0\SDK\Boostrapper\"
</GenerateBootstrapper>
with this the MSBuild is able to recognize and generate the file
Now i'm stucked with the .net 4 bootstrapper but guess is another story...
I experienced this same error via my TeamCity build server. The cause in my case was that I was running an MSBuild task against my .sln file, with a 'MyProject:publish' target. In this case, the solution+projecth had been updated to target .NET v4.5, but the build server was still configured to use MSBuild Tools 4.0 and .NET v4.0.
Took me a little while to work out the inconsistency between working and non-working branch builds.
I added this line to script. It helped.
call "%VS120COMNTOOLS%vsvars32.bat"
Visual Studio 2013, SDK v8.1A.
Just struggled with this myself - I chose to commit the bootstrapper files to source control. It is possible to override the path to bootstrappers, just provide /p:GenerateBootstrapperSdkPath=.build\Bootstrapper
Then no need to modify registry - and the added benefit that the build is now self-contained.
Only "problem" is that I have to manually copy the Bootstrapper files into source control. In my case (VStudio2015), this meant copying the files from C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper