Visual Studio 2017 includes a project template for creating optional packages in C#. However, there is no corresponding project template for C++/WinRT. Is there any way to create the same kind of optional package using C++/WinRT in Visual Studio?
There's no separate 'Optional Code Package' visual studio template for C++\WinRT. Please see the OptionalPackageSample repository on GitHub. It creates a OptionalPackageDLL
to show how to create a project with code that can be executed from the main package. The MyMainApp project demonstrates how to load code from the OptionalPackageDLL.dll file.
The scenario is:
1. Created a NEW solution
2. ENABLED download missing packages
3. Add projects to solution that already exists and depends on nuget packages
4. Building the solution generates an error:
... The missing file is <solution folder>\.nuget\NuGet.targets.
Why? Have missing something?
I'm using Visual Studio 2017 Pro on Windows 10
All my searches answer about the scenario where create a new solution and adds a new project that depends on nuget package, that's ok, but when have an existing project, nothing.
<solution folder>\.nuget\NuGet.targets is a file that NuGet's Visual Studio extension used to add in Visual Studio 2010, 2012 and 2013 when you right click on the solution and select "Enable NuGet Package Restore". It would then add an import in all of your project files to import the targets file. I was recently investigating a customer issue and as part of that investigation I found it made the following changes. Near the top of the csproj, it adds something like this:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
<RestorePackages>true</RestorePackages>
and near the end of the csproj it adds somthing like this:
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
So, the problem is that you're creating a new solution, but using existing project files that have been modified in this way. One option is to edit your csrpoj files and remove these changes. Another option is to create new projects, in addition to the new solution, and then copy all your code and content files.
The only disadvantage is if you build on a CI server and use packages.config, your build script needs to run nuget.exe restore, whereas projects that use NuGet.targets could just build the solution and msbuild would execute nuget restore as needed. One advantage of no longer using NuGet.targets is that restoring the whole solution is faster than restoring project by project. Visual Studio automatically restores packages on build, even in VS2010, VS2012 and VS2013, so personally I discourage the use of using this feature, even if you use those old versions of Visual Studio. The benefit of reducing your build script by one step is not worth the issues it brings, in my opinion.
The last windows update has broken our whole build chain and I am a little at a loss at what causes it.
I have a legacy project that is a VS 2017 solution with a significant number of projects (winform, couple web based, some Webapi only).
Locally things work perfectly. I can just build them.
On the server, the proejct has started to fail, and the error is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.
Process 'msbuild.exe' exited with code '1'.
I have added
<RuntimeIdentifiers>win</RuntimeIdentifiers>
To a number of projects. No change. I am at a loss, because the error message does not even tell me which project.
At some point before attempting to build, you need to delete the obj folder.
More than one person showed this to solve the problem.
https://developercommunity.visualstudio.com/content/problem/312180/projects-fail-to-build-in-1580-due-to-errors-from.html
Although #Señor CMasMas's answer has helped me in the past, I'm now finding (since installing the .NET Core SDK v2.2 - I don't know if that's related though) that I also need to close and reopen Visual Studio. So for me the recipe is:
Clean solution
Delete obj folders
Delete the .vs folder (optional, if you get red lines but it builds OK)
Close and reopen Visual Studio
Then build
Add this: <RuntimeIdentifier>win</RuntimeIdentifier>
to your project file, for example after element TargetFrameworkVersion. Make sure the element name is singular. RuntimeIdentifiers on the other hand is used in the new csproj format
Or you just can run in the root directory of your project the script in PowerShell that you should run as administrator.
Get-ChildItem .\ -include bin,obj -Recurse | foreach { remove-item $_.fullname -Force -Recurse }
this script will delete all obj and bin folders
I have come across same error in Vs 2019 (16.8.6), following steps resolved my problem.
Close visual studio (other visual studio instances may remain)
Delete all bin and obj folders in all projects in the solution
Reopen solution and Build
Note that if bin folders exist, deleting only obj folders doesn't work, you need to delete bin folders too.
Had this problem in projects using packageReference when manually restoring packages by running
NuGet.exe restore my.sln
as part of a TeamCity build (so might be related nf313743's answer https://stackoverflow.com/a/60951212/128384) and then building projects using msbuild.
This would result in the following error when msbuild begins dealing with the PackageReference:
[ResolveNuGetPackageAssets] C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186, 5):
Your project file doesn't list 'win-x86' as a "RuntimeIdentifier". You should add 'win-x86' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.
Deleting obj directories etc doesn't work here because they get added by the restore step; adding a RuntimeIdentifier might, but building the exact same on a VS2017 commandline works fine so clearly the difference is in how TeamCity sets up the environment.
The culprit could be found in the output of the first call:
NuGet.exe restore my.sln -NonInteractive
MSBuild auto-detection: using msbuild version '16.10.2.30804'
from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\bin'.
it uses msbuild from the VS2019 installation whereas the project is being built by VS2017, so somewhere in mixing those there is an incompatibility which is not unexpected. Anyway, the key is likely that TeamCity doesn't setup a complete environment like the VS2017 commandline does and the NuGet documentation says
By default the MSBuild in your path is picked,
otherwise it defaults to the highest installed version of MSBuild.
so that's why it uses the VS2019 one. Solution is to manually pass -MsBuildPath to NuGet and set it to what corresponds to the selected buildtools in teamCity, in this case:
NuGet.exe -msBuildPath "%MSBuildTools15.0_x86_Path%" restore my.sln
(and it turns out teamCity itself is also plagued by this in its own NuGet step: How to set the MSBuild verision for TeamCity NuGet Installer?)
I have a similar case. I try to build a solution via msbuild without installing Visual Studio 2017, just install the latest version of vs 2017 build tools. Here are my steps:
dotnet restore a.sln
(There are some .Net Standard Library project in this solution, the others are .NET 4.7.2 projects).
call msbuild.exe to build this solution.
I got the error of "missing RuntimeIdentifier".
Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.
It seems an issue in the old version of Nuget. Please refer here. Finally, I resolved it via restore packages with the latest Nuget (v5.0.2).
the steps:
Delete obj and bin folders
nuget.exe restore a.sln
call msbuild.exe
I had a similar problem. My error was
error : Your project file doesn't list 'win10' as a
"RuntimeIdentifier". You should add 'win10' to the
"RuntimeIdentifiers" property in your project file and then re-run
NuGet restore.
Well, it turned out I just had to change by build target from "Any CPU" to something else (x64 for example)...
you got to figure out which projects in your solution trigger this error. you can find this if you look at the error panel.
go to that projects locations and delete both the bin and the obj folders.
then rebuild.
should be alright
I had this same issue toggling across vstools build chains (VS2017/VS2019) - here is what fixed it for me - brute force clean via rimraf
Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" proper ty in your project file and then re-run NuGet restore
Remove Intermediary Build Output Artifacts
rimraf *\obj\**
The RuntimeIdentifier should look something more like what's described here: https://learn.microsoft.com/en-us/dotnet/core/rid-catalog.
Given this appears to build just find locally, I'd diff the .csproj on your local machine against the one on your build server. Something tells me, they are not identical.
FWIW, Line 186 in the noted Microsoft.NuGet.targets file, is running the ResolveNuGetPackageAssets task, and you can see the RuntimeIdentifier argument being passed as the NuGetRuntimeIdentifier property. You could probably backtrace that in your working build's diagnostic log to see how it's being assigned.
But given this works on one box, and not on another, I'd just dbl check your project files and verify that the RuntimeIdentifier tag identical on both systems.
Sincerely,
So I was seeing the same error message as this on our on premises DevOps build server, but it built fine locally in Visual Studio as well as via the msbuild on the command line.
I checked and I DID have the <RuntimeIdentifiers> defined in my project file and clearing out the obj and bin folders on the server did NOT fix it for me.
Our issue was we had the < RunTimeIdentifiers> tag showing up MULTIPLE times in the build section,(probably from a bad merge at some point in the past). After removing the duplicate tags, DevOps successfully built the project.
I was googling for hours and never stumbled on this being the cause of the issue for anyone else. Hopefully this saves someone else some time in the future if they have the same problem.
For me, it was as simple as compiling a Windows IoT App with x86 platform instead of ARM.
In my case, this was happening on an Azure build.
I was able to resolve it by forcing the build to use Visual Studio 2019 tools.
I modified our build.cake file so that the MSBuild steps included the UseToolVersion for VS 2019 like this:
MSBuild(_solutionFile, settings => settings.SetConfiguration(_configuration)
.UseToolVersion(MSBuildToolVersion.VS2019));
The only thing that worked for me was to delete ALL project files and download them again from the version control. Then the problem disappeared.
If you are targeting Azure Service Fabric or other 64-bit environment, check that you have a consistent <PlatformTarget>x64</PlatformTarget> in all configurations defined in the CSPROJ file. In my case it built just fine locally but failed on the CI server because one of the many configurations had <PlatformTarget>AnyCPU</PlatformTarget>.
I was receiving the same error as the original poster, with Msbuild v15.9.21
Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore
My projects are .net Framework v4.6.2. The projects build fine locally using VS 2017, but failed when building on TeamCity Enterprise 10.0.5. I had recently converted my projects from .package to PackageReference - this causing the build to fail.
My solution was to add a new build step to explictly restore the solution's nuget packages before building the solution. It seems that before converting the projects to PackageReference this was being done on the build step implicitly.
I always get this error in the Azure pipeline. So far I have noticed the following fixed for me in various occasions:
1. do not commit the .suo file - if so, delete and recommit
2. do not commit the bin or obj folders - if so, delete and recommit
3. if there is a new project added, set the project dependency on the solution properties - save and commit the .sln file
I had same issue with one of the unit test project failing to compile after I upgraded to VS to 15.9.27 and the solution to delete the obj folder worked for me
A simple nuget restore before calling MSBuild worked for me. I have projects targeting .NET Framework 4.7.2 (not SDK Style, legacy style) which I migrated from packages.config syntax.
I experienced this issue with a MSBUILD project that I've added into a solution of VS2015 and VS2019, that project was compiled with VS2010. I just excluded it from solution and compiled it with VS2010, including the .DLL file into other projects that work with VS2015 and VS2019.
To projects mult-target fmk
Add this to your project file, for example:
<PropertyGroup>
<RuntimeIdentifier>ubuntu.16.04-x64</RuntimeIdentifier>
</PropertyGroup>
or
<PropertyGroup>
<RuntimeIdentifier>win</RuntimeIdentifier>
</PropertyGroup>
I'm using VS 2019 (16.11.17). I was working in 2022 on a different branch.
I tried all of these solutions and none worked, until I deleted the solution folder and cloned fresh.
I'm building a new TFS build server and decided to use the VS 2017 Build Tools instead of installing the full versions of VS. When I attempt to build our C++ projects, it throws the following error:
Error MSB4019: The imported project "D:\Microsoft.Cpp.Default.props" was not found.
After many hours of research I'm no closer to resolving this issue. I tried adding the following registry settings but it did not help.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\11.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
I'm guessing Microsoft's installer is broken for this product. Is there a standard fix for this error or should I scrap my efforts and simply install the full versions?
In the project file, I found this entry:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
So, I guess this means that the variable VSTargetsPath is somehow pointing to the root of the D: drive but I haven't got a clue where that value is being set. Our current build server does not have an environment variable set named VSTargetsPath, but it does have the missing registry entries. It also has full versions of VS installed.
VS 2017 Build Tools failing with Error MSB4019: The imported project “D:\Microsoft.Cpp.Default.props” was not found
Try to pass VCTargetsPath explicitly as property to msbuild from your build configuration:
Edit the build definition for the build.
Click the process tab.
In the Advanced section, set the MSBuild Arguments to include the following property:
/p:VCTargetsPath="C:\Program Files (x86)\Microsoft Visual Studio\2017\xxx\Common7\IDE\VC\VCTargets\"
Save the build definition.
Note: You should change the value of VCTargetsPath to the location of the VCTargets folder.
Or pass VisualStudioVersion as property to msbuild:/p:VisualStudioVersion=15.0
If you are interesting in the value of $(VCTargetsPath), you can check following threads for some more details:
Can't find registry entries for Visual Studio 2017
Visual Studio Locator
Over the years Visual Studio could be discovered using registry keys,
but with recent changes to the deployment and extensibility models a
new method is needed to discover possibly more than once installed
instance. These changes facilitate a smaller, faster default install
complimented by on-demand install of other workloads and components.
vswhere is designed to be a redistributable, single-file executable
that can be used in build or deployment scripts to find where Visual
Studio - or other products in the Visual Studio family - is located.
For example, if you know the relative path to MSBuild, you can find
the root of the Visual Studio install and combine the paths to find
what you need.
You can emit different formats for information based on what your
scripts can consume, including plain text, JSON, and XML. Pull
requests may be accepted for other common formats as well.
vswhere is included with the installer as of Visual Studio 2017
version 15.2 and later, and can be found at the following location:
%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe.
I am attempting to build a C++ project in a Visual Studio 2013 solution on TC 8.0.6 (build 27767).
I have installed the latest MSBuild "Microsoft Build Tools 2013" stuff (which is normally installed as part of VS 2013 install) directly on the server.
But I get the following error:
[17:05:23]VCTargetsPath is c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\
[17:05:23]PlatformToolset is v120
[17:05:23]VCMessage
[17:05:23]c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32
Microsoft.Cpp.Win32.Targets(512, 5): error MSB8008: Specified platform toolset (v120) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.
[17:05:23]Project MyCppProject\smCpp.vcxproj failed
As far as I can see I have everything I need and I have tried various hacks to set the PlatformToolset to v110 etc., but that doesn't work either.
At this stage I would like to verify exactly what I need to install on the build server. Can someone clarify if I need anything extra please?
Many thanks
Brian
Ultimately you need to set the correct path to MSBuild. With VS 2013, build tooling became part of VS rather than .NET, making it version 12.0 instead of 4.0. The default path in this instance is:
"C:\Program Files (x86)\MSBuild\12.0\bin"
If the team foundation build is broken then it's likely because the TF server is not on version 2013. To fix the problem you need to make yourself a copy of the build template the build definition uses (assuming your version is >= 2010 and < 2013) and point to the correct tooling folder. The build templates are located in the following source path:
$/YourTeamProjectName/BuildProcessTemplates
If you can edit the template in Visual Studio you open the Workflow Foundation design surface. In there find the Run MSBuild for Project tasks (note in the default template there is more than one, but I've shown a pic of what to look for) and change the tool path property to the above path.
Once you created the template you need to change your build definition to use the new template.
For TeamCity you need to set the MSBuild ToolsVersion to version 12.0 in your build step. I'm not sure what version of TC started support for version 12.