"No executable found matching command dotnet-ef" error with EF Core database-first - visual-studio

As you know, the newest version of Visual Studio 2017 abandons the 'project.json' and uses .csproj instead.
I'm using the RTM version and want to generate model from an exist database, following this guide. I got an error on the last step:
The Entity Framework Core commands for the Package Manager Console don't yet support csproj-based .NET Core projects. Use the .NET Command Line Tools (i.e. dotnet ef) instead. For more details, see https://go.microsoft.com/fwlink/?linkid=834381.
Following the error, I used the link it mentioned to switch to dotnet ef. Here is my package manager command:
PM> dotnet ef dbcontext scaffold "Server=.;Database=Jumpstart;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer
Then the error comes again:
dotnet : No executable found matching command "dotnet-ef"
I used the help command, I found that dotnet does not have a command called ef.
I just want to generate a model from an existing database.

Follow this tutorial
https://learn.microsoft.com/en-us/aspnet/core/data/ef-mvc/migrations
I had the same problem. Just edited the ItemGroup section in .csproj like this
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0" />
</ItemGroup>

Accepted answer is the most probable cause of the error message. However, besides adding the proper reference within .csproj file also make sure that the current directory from Package Manager Console points to ASP.NET Core project, otherwise any dotnet ef command will fail with the error mentioned in the OP title.

My issue was solved by changing tools to:
"tools": {
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.1.0-preview4-final",
"Microsoft.EntityFrameworkCore.Tools.DotNet": "1.1.0-preview4-final"
},
Then execute these 2 commands:
dotnet restore - to restore packages
dotnet ef migrations

I solved the problem
in all answer mentioned adding Tools DotNet but not solved my problem because missed some command I mention below
The EF Core .NET Command Line Tools are installed by manually editing the *.csproj file.
Add Microsoft.EntityFrameworkCore.Tools.DotNet as a DotNetCliToolReference. See sample project below.
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0" />
</ItemGroup>
for core version 2 changed the version
but after that should run 2 commands too
then importatn part in all answer missing (this command solved my problem in visuall studio 2017)
1 - Execute dotnet add package Microsoft.EntityFrameworkCore.Design
2 - Execute dotnet restore. If restore does not succeed, the tools may not have installed correctly.
more information
https://learn.microsoft.com/en-us/ef/core/miscellaneous/cli/dotnet

On NetCore 2.0 you just need to run Add-Migrations.
It will ask for a name and that's all. Just be sure you have a default connection string on appsettings.json

Related

The specified deps.json [] does not exist

I'm using Asp.net Core with EntityFramework.Core. I'm having troubleshot migrations and Scaffold after format my pc.
when I write these in Package Manager Console
Scaffold-DbContext "Data Source=.\SQL2017DEV;Initial Catalog=MyDataBase;Integrated Security=True" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Db
Add-Migration Initial
error is
"The specified deps.json [D:\TFS\Erdi\Erdi\AspCoreWeb.Site\AspCoreWeb.Site.deps.json] does not exist"
[MyProjectFolder]\AspCoreWeb.Site.deps.json
I think it try to find my debug folder.
This solutioun is working other computers
I'm repair my visual studio but it hasn't changed
In my case; was fixed by changing the Startup Project (via Solution Properties) to the project that has EF Context file.
There is an issue with migration in VS2019. I have been facing a similar issue and was getting below error:
The specified deps.json [YourProjectLocation]\ProjectName.deps.json doesn't exists.
When I used dotnet CLI for migrations and it worked and was able to generate migration and update the same using dotnet CLI.
dotnet ef migrations add InitialCreate
dotnet ef database update
this problem generally occurs because of path issues. You should change your "outputPath" in the "project.assets.json" file.
D:\TFS\Erdi\Erdi\AspCoreWeb.Site\AspCoreWeb.Site.deps.json] instead of this,
D:\TFS\Erdi\Erdi\AspCoreWeb.Site\obj\AspCoreWeb.Site.deps.json]
i think this will resolve your problem.
If you are using Package Manager Console to "Add-Migration" or "Update-Database", be sure that the project where you want the migration is selected as the Startup project in Visual Studio and this project is also the default in Package Manager Console.
Solution Explorer:
Package Manager Console:
If you are using the dotnet CLI, then you have to navigate to the right project folder and run the migration commands from there.
Make sure that the Startup Project is where the connection string is and select the project in the Default project of Package Manager Console where the db context is at.
Just Go to VS 2022
It Worked for me
go to bin folder and copy files in it include deps.json to the path that see in error.

Error NU1105 Unable to find project information - The project file may be invalid or missing targets required for restore

All of a sudden, I am getting the following errors for 3 projects in a solution:
Error NU1105 Unable to find project information for 'C:\code\example\src\libs\example.I18n\example.I18n.csproj'.
The project file may be invalid or missing targets required for restore.
The only thing that has changed in the project is a couple of DB changes, but I never had any issues in the past. The only other thing is that I updated to Visual Studio 2017 15.5. Could that cause issues?
I have tried removing and recloning the solution from source control, but still getting errors. No problems on my colleagues' machines, so it must be something local.
Example of one of the .csproj files if this helps:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net452</TargetFramework>
<AssemblyName>Example.I18n</AssemblyName>
<PackageId>Example.I18n</PackageId>
<GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
<GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
<GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="1.1.2" />
<PackageReference Include="Microsoft.Extensions.Logging" Version="1.1.1" />
<PackageReference Include="MessageFormat" Version="1.0.1" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'net452' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
</Project>
I also got the same after upgrading to version 15.6 of Visual Studio 2017.
Closing VS and deleting the .vs folder fixed it for me.
For me, the casing of the project file on disk did not match the casing in the solution file.
Say I had a solution with LibraryA.csproj and LibraryB.csproj, where LibraryB.csproj has a reference to LibraryA.csproj. Having an incorrect casing for LibraryA.csproj in the solution file would cause NU1105 when building LibraryB.csproj:
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "LibraryA", "LibraryA\Librarya.csproj", "{24DEBB3B-762A-491D-8B83-6D078C0B30C0}"
I started seeing this problem after upgrading to version 15.5 of Visual Studio 2017. I did not encounter this problem with version 15.4.5.
I had this problem and I just followed what the error message recommends inside VS:
to restore the solution.
So I opened a command line or package manager console, chdir into the directory with the solution (.sln) file and just issued
C:> dotnet restore .\mySolution.sln
Problem was fixed.
This error message will also occur if a referenced project is not included in the solution. I encountered this problem today, and I found the fix here.
I encountered this error when having a duplicate reference to a project.
<ProjectReference Include="..\ProjectA.csproj" />
<ProjectReference Include="..\ProjectA.csproj" />
Removing the duplicate reference resolved the error.
What worked for me was to
Remove the offending project
Build the solution
Re-add the project.
Seems that some projects were removed from solution file (don't know why). Fixed by undoing these solution file changes
I have next project structure (.Net Core projects):
../classLib
../../../webProject1
../../../webProject2
../../myWebProjects.sln
webProject1 and webProject2 reference classLib as project itself (not as .dll). When I opened my solution in VS 2019 and tried to build I got identical error NU1105: Unable to find project information for '../classLib.csproj'. error.
Before build depended projects you need to restore there dependency. What I did, just add
next Target to my webProject1.csproj and webProject2.csprojfiles.
<Target Name="PreBuild" BeforeTargets="PreBuildEvent">
<Exec Command="dotnet restore" />
</Target>
Open powershell and running restore command solved my issue.
dotnet restore Sample.sln
I correct this error by simply running the clean solution option.
Right click the solution in the solution explorer and choose clean solution.
This is insane, i tried all this:
updated VS. manually deleted all bin folders, run dotnet restore, clean rebuild nothing works
solution: finally i unload all the projects and start reloading them into solution, one by one in the order they show dependency errors. then the last one just cascade fixes everything. No idea what was wrong
I recently came across Error NU1105 while using JetBrains Rider on Linux. So this involves Mono and the MSBuild version that comes with it.
It turns out this was being caused by my solution files being in a directory that was a symbolic link to another directory. I believe MSBuild was dereferencing the linked directory and instead referencing the source directory. This makes some of the referenced paths completely different, even though they are the exact same files, case, everything else. Opening the solution from the original location works perfectly now for me.
Reload the project which causes the problem, this will fix the issue,
As mentioned in the following link :
https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu1105
This happend to me when I had files with names exceeding OS's max path limit. Check your names ;)
In my case I did it and it worked for me
goto Tools/CommandLine/Developer Command Prompt or Developer Powershell
type this command and Enter "dotnet restore".
Build your solution
That's all
Just use: "dotnet restore MySolution.sln",
Where MySolution.sln is your solution.
I was getting this error error NU1105: Unable to find project information for 'C:\folder2\project1.csproj'.
but project1 that I had as part of the solution was located in C:\folder1\project1.csproj (it was also there in c:\folder2\project1.csproj too but not part of the solution, so it was confusing)
Once I changed the reference to the correct location of the project it worked.
After spending 3 hours, trying out numerous solutions, what worked for me is that I had to undo my root solution sln file...some of the project references were removed..not sure how.

NuGet restoring PostSharp package before the build begins

I am using PostSharp and I have the following target description in my project file:
<Target Name="EnsurePostSharpImported" BeforeTargets="BeforeBuild" Condition="'$(PostSharp30Imported)' == ''">
<Error Condition="!Exists('..\..\packages\PostSharp.3.1.33\tools\PostSharp.targets')" Text="This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://www.postsharp.net/links/nuget-restore." />
<Error Condition="Exists('..\..\packages\PostSharp.3.1.33\tools\PostSharp.targets')" Text="The build restored NuGet packages. Build the project again to include these packages in the build. For more information, see http://www.postsharp.net/links/nuget-restore." />
</Target>
As far as I understand, this is added to the project when PostSharp is referenced through NuGet, and the error conditions check the following:
The first error condition breaks the build when PostSharp is not available (i.e. NuGet did not restore it successfully).
The second error condition breaks the build when PostSharp was successfully restored by NuGet on the last build but was therefore not included in the project, so therefore a rebuild is necessary.
BUT, if I have the following configuration in NuGet.Config and .csproj file, is the second error condition even necessary?
NuGet.Config file:
<configuration>
<packageRestore>
<!-- Allow NuGet to download missing packages -->
<add key="enabled" value="True" />
<!-- Automatically check for missing packages during build in Visual Studio -->
<add key="automatic" value="True" />
</packageRestore>
...
</configuration>
.csproj file:
<RestorePackages>true</RestorePackages>
As far as I understand, NuGet will then restore the missing packages BEFORE the build even starts. The second error condition will essentially break the build for no reason at all.
Note: I am using Visual Studio 2013 and NuGet 2.8.
It depends on how the restore is done and which version of NuGet you have installed. It looks like the error messages are trying to cover three scenarios:
Building without the MSBuild based package restore enabled (which is configured inside Visual Studio by right clicking the solution and selecting Enable Package restore).
Building outside of Visual Studio when the MSBuild based package restore is not enabled.
Building with Visual Studio using an old version of NuGet which does not support the automatic restore before a build.
If you are using the MSBuild based package restore then the restore will occur during the build and the PostSharp files will not be imported at this point so the $(PostSharp30Imported) will be empty and the second error message will be displayed. At least I suspect that is the case.
If you building from the command line and not using the MSBuild based package restore then you would see the first error message if the NuGet packages were missing.
If you are not using the MSBuild based package restore, and are building from within Visual Studio with a recent version of NuGet, then you are correct that the packages will be restored before anything is built at all. So the PostSharp imports should be available to MSBuild before it is even executed.
As PostSharp dlls are required during msbuild loading (so targets referencing this dlls are available during build) they must be available during final call to msbuild.
While in VS it is acceptable to click build twice, I was using PostSharp in CI environment, and requirement to call build on solution two times was frustrating (first build restore nugets but also failed build due to error).
I ended up with separate build steps:
Restore nuget Packages (this downloads PostSharp packages and return success code to environment):
NuGet.exe restore SolutionWithProjectsUsingPostSharp.sln
Build solution.
You need to edit the second error condition in the target in the csproj
<Target Name="EnsurePostSharpImported" BeforeTargets="BeforeBuild" Condition="'$(PostSharp30Imported)' == ''">
<Error Condition="!Exists('....\packages\PostSharp.3.1.33\tools\PostSharp.targets')" Text="This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://www.postsharp.net/links/nuget-restore." />
<Error Condition="Exists('....\packages\PostSharp.3.1.33\tools\PostSharp.targets')" Text="The build restored NuGet packages. Build the project again to include these packages in the build. For more information, see http://www.postsharp.net/links/nuget-restore." />
</Target>>
I have answered in detail in a different post at SO
We are using 'old' MSBuild-Integrated package restore ( .nuget\NuGet.targets file is present) and normally do not store in source control packages, but rely on build to restore them for each build.
But for PostSharp on TeamCity build server I am getting error :
The build restored NuGet packages. Build the project again to include
these packages in the build.
The simplest way is to explicitly include in source control packages\PostSharp.VerXXX.
Alternatively solution could be migrating to automatic package restore,
as it was advised in Issue Using PostSharp 3.x with NuGet Auto Restore
Right click on the solution, Manage Nuget packages; and remove the packages you dont want .
This error also shows up , when trying to restore the packages from the web. Just connect your self to the internet and then try opening the project.
The errors went away for me on following the above steps.

TransformXml task could not be loaded from Microsoft.Web.Publishing.Tasks.dll

Has anyone seen this error and know how to fix it?
The "TransformXml" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll.
Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll' or one of its dependencies. The system cannot find the file specified.
Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
I read elsewhere that the problem is when you don't have SQL Server installed. But I do have SQL Express 2012 x64 installed with SP1. I am also running VS 2013 Professional.
I have ran this exact same solution in VS 2012 express with no problems.
The answers provided by Dai Bok and emalamisura work fine as long as you use Visual Studio 2012.
For VS 2013 this fails as well. In order to make this work with all versions of Visual Studio you should:
Open the project file (.csproj) of the project failing to load
Search for <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />
Change it to <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.targets" />
Reload the project
That will set the correct version of Visual Studio dynamically and properly.
To get mine to work, I just copied my v10.0 folder and renamed it to v11.0, and things seems to work well from then on. That's the quick fix for now.
As this is probably not the best solution, and although it works, I was going to try installing the Microsoft Windows SDK for Windows 7 and .NET Framework 4 Windows SDK for Windows 7 and .NET Framework 4, but it is taking to long to download.
To fix the issue,
Find the Visual studio Installer in your computer
Click or tap to start the installer, and then select Modify.
From the Individual Components screen, select Asp.net and web development tools and then select Modify/Install.
This solved the issue as it creates the dll's in the mentioned path.
I've been combating this problem on our build server for several days, so I figured I'd document the resolution I came to. First, my build server has the web publishing extensions installed. I can use the TransformXml task to my heart's content inside of a web application project.
To use it outside of a web application project, I tried to add the UsingTask element to my project and point it to the right place using ms build properties (as Benjamin demonstrated). However, they weren't there on my build server (those with easy access to the file system of their build server can probably skip this and just install the relevant package to Visual Studio). I even went so far as to hard code visual studio versions, but it always dropped that error on me.
I finally gave up, pulled the DLLs from my local PC:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.Tasks.dll
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.XmlTransform.dll
I uploaded them to source control and added that folder to my build's workspace (Edit Build Definition -> Source Settings -> Source Control Folder). From there, I don't even need to reference the folder -- here's what my UsingTask looks like:
<UsingTask TaskName="TransformXml" AssemblyFile="Microsoft.Web.Publishing.Tasks.dll" />
Now I can use the TransformXml task to my heart's content from any project.
For VS2019
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(MSBuildToolsVersion
I replaced MSBuildToolsVersion with VisualStudioVersion.
Because there are only v12.0, v14.0 and v15.0 in my VisualStudio folder, I edit my project file and change the reference path from v10.0 to v14.0. Then the project builds successfully.
Before:
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
After:
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
Solutions provided seem to work for using VS as an IDE, but if you use DotnetCore via CLI or on a unix based system this does not work.
I found that the following seem to work
<PropertyGroup>
<XmlTransformDllPath Condition="'$(XmlTransformDllPath)' == '' AND '$(MSBuildRuntimeType)' == 'core'">$(MSBuildSDKsPath)/Microsoft.NET.Sdk.Publish/tools/net5.0/Microsoft.NET.Sdk.Publish.Tasks.dll</XmlTransformDllPath>
<XmlTransformDllPath Condition="'$(XmlTransformDllPath)' == '' AND '$(MSBuildRuntimeType)' != 'core'">$(MSBuildSDKsPath)/Microsoft.NET.Sdk.Publish/tools/net472/Microsoft.NET.Sdk.Publish.Tasks.dll</XmlTransformDllPath>
<XmlTransformDllPath Condition="!Exists($(XmlTransformDllPath))">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll</XmlTransformDllPath>
</PropertyGroup>
<UsingTask TaskName="TransformXml" AssemblyFile="$(XmlTransformDllPath)" />
This solution takes into account netcore, full .net
For some reason MSBuildSDKsPath and MSBuildExtensionsPath32 are different on windows when using CLI vs VS2019
CLI:
MSBuildSDKsPath = C:\Program Files\dotnet\sdk\5.0.103\Sdks
MSBuildExtensionsPath32 = C:\Program Files\dotnet\sdk\5.0.103
Vs2019
MSBuildSDKsPath = C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Sdks
MSBuildExtensionsPath32 = C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild
Which on my Mac returns /usr/local/share/dotnet/sdk/5.0.201
Only problem I see is with the tools/net5.0 part of the name which changes ever release
Also created https://github.com/dotnet/sdk/issues/16469 and answers this on The "TransformXml" task was not found (error MSB4036) on TeamCity build
The correct answer to this is to unload the project in question and then edit the csproj file, look for an entry where they are referencing the 10.0 path and change it to point to 11.0 instead.
You need two things to make it work:
1) Install Visual Studio Build Tools (You don't need the whole Visual Studio, only the VS Build Tools) with selected "Web development build tools" option on your build server
https://www.visualstudio.com/pl/thank-you-downloading-visual-studio/?sku=BuildTools&rel=15
2) Ensure that path to Microsoft.Web.Publishing.Tasks.dll is correct
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(MSBuildToolsVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
For me it started working just by adding reference to the NuGet package MSBuild.Microsoft.VisualStudio.Web.targets v14.0.0.3
Even no need to add UsingTask element to the project file as it mentioned by the package author
https://github.com/pdonald/nuget-webtargets
Just install the NuGet package. The package automatically sets the
$(VSToolsPath) property to use the targets file in the tools folder.
And then I was able to use TransformXml and other tasks, defined in the package, for instance to transform app.config
<Target Name="app_config_AfterCompile" AfterTargets="AfterCompile" Condition="Exists('app.$(Configuration).config')">
<!--Generate transformed app config in the intermediate directory-->
<TransformXml Source="app.config" Destination="$(IntermediateOutputPath)$(TargetFileName).config" Transform="app.$(Configuration).config" />
<!--Force build process to use the transformed configuration file from now on.-->
<ItemGroup>
<AppConfigWithTargetPath Remove="App.config" />
<AppConfigWithTargetPath Include="$(IntermediateOutputPath)$(TargetFileName).config">
<TargetPath>$(TargetFileName).config</TargetPath>
</AppConfigWithTargetPath>
</ItemGroup>
</Target>
Just in case someone is using an SDK-style csproj, you can achieve this without having to install Visual Studio on the build server.
First you should install the SlowCheetah nuget package to your project. Once you install it, you'll see the following in your SDK-style project.
<PackageReference Include="Microsoft.VisualStudio.SlowCheetah" Version="3.2.20">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>
Then make sure you add the GeneratePathProperty="true" attribute (see below). This is very important for the next part because it'll help you grab the path of where the nuget package is restored on your machine. George Dangl explains it in his article here.
<PackageReference Include="Microsoft.VisualStudio.SlowCheetah" Version="3.2.20" GeneratePathProperty="true">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>
Import the SlowCheetah targets into your project:
<Import Project="$(PkgMicrosoft_VisualStudio_SlowCheetah)\build\Microsoft.VisualStudio.SlowCheetah.targets" />
You can now use an target command (in this case after publish) to apply some custom transformations. If you need to, you can always hard-code the file names below instead of using the variables in the below example.
<Target Name="AfterPublishs" AfterTargets="Publish">
<TransformTask Source="Web.config" Transform="Web.$(Configuration).MyCustomTransformFile.config" Destination="$(PublishDir)\Web.config" />
</Target>
If you haven't used SlowCheetah before, I recommend checking it out. They have a Visual Studio extension that will make it easier for you to preview transform files.

How to set SGEN toolpath in Msbuild to target 3.5 framework

I've just upgraded a project from VS2008 to VS2010 but I'm still targeting the 3.5 framework.
In my project file I have a custom task to run SGEN to generate my XmlSerializers.dll. However the version of sgen being run targets the 4.0 framework. As a result, when I run my application I get the error message:
"Could not load file or assembly 'XXXX.XXXX.XmlSerializers' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."
The Sgen task looks like this:
<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);#(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
<!-- Delete the file because I can't figure out how to force the SGen task. -->
<Delete Files="$(TargetDir)$(TargetName).XmlSerializers.dll" ContinueOnError="true" />
<SGen BuildAssemblyName="$(TargetFileName)" BuildAssemblyPath="$(OutputPath)" References="#(ReferencePath)" ShouldGenerateSerializer="true" UseProxyTypes="false" KeyContainer="$(KeyContainerName)" KeyFile="$(KeyOriginatorFile)" DelaySign="$(DelaySign)" ToolPath="$(SGenToolPath)">
<Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly" />
</SGen>
</Target>
There's the ToolPath="$(SGenToolPath)". How do I make it run the version that targets 3.5?
There's a similar question here but it doesn't help me much.
I have solved this by manually configuring the ToolPath to point to the old (version 2.0.50727.3038) version of sgen.exe
On my machine, this is in: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
I changed the ToolPath attribute to be:
ToolPath="C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin"
and this solved the problem.
It seems, by default, it's running the new 4.0 framework version in: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools
Hope this helps somebody else.
MSBuild uses the registry to get the path to the v3.5 tools. The MSBuild tasks that require v3.5 SDK tools will fall back to the v4.0 path if the path to the 3.5 tools can't be identified - look at the logic used to set the TargetFrameworkSDKToolsDirectory property in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.NETFramework.props if you're really interested.
You can diagnose and fix this problem as follows:
Install Process Monitor and set up a filter to monitor registry access by msbuild (Event class: Registry, Process Name: msbuild.exe, all types of result).
Run your build.
Search Process Monitor for a RegQueryValue access matching "MSBuild\ToolsVersions\4.0\SDK35ToolsPath". Note that this could be be under either "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft" or "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft".
If you have a look at this key in the registry, you'll see that it aliases another registry value, e.g. "$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools-x86#InstallationFolder)"
Shortly after this, you'll probably see a "NAME NOT FOUND" result. If you look at where the expected key should be, you'll see that they don't match the key being requested (missing hyphens and possibly no key ending with "-86").
It should be clear what you need to correct. I chose to export the incorrect keys, edit the .reg file and run it to create the correct keys.
One cause of invalid registry entries could be a bug with the Microsoft SDK v7.1 installation:
http://connect.microsoft.com/VisualStudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-net-3-5-generates-wrong-embedded-resources
I found this to be the easiest way and it works with: <GenerateSerializationAssemblies>On</ GenerateSerializationAssemblies>
<SGenToolPath>C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin</SGenToolPath>
The problem is $(SGenToolPath) isn't set by MSBuild. If you use $(TargetFrameworkSDKToolsDirectory) then it will attempt to resolve the path based on $(TargetFrameworkVersion).
Its helpful to make use of tags for printf() style debugging. Add the following temporally.
<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);#(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
<Message Text="SGenPath: $(SGenPath)" Importance="high"/>
<Message Text="TargetFrameworkVersion: $(TargetFrameworkVersion)" Importance="high"/>
<Message Text="TargetFrameworkSDKToolsDirectory : $(TargetFrameworkSDKToolsDirectory )" Importance="high"/>
#Craig - Did you manually install the 7.0A framework on your build machine. If so, your problem may be your registry settings and not msbuild. Take a look at LocalMachine -> Software -> Microsoft -> MSBuild -> ToolsVersions -> 4.0 -> SDK35ToolsPath and make sure the reg key that is referenced there is valid. (Hint: Make sure the -x86 is there only if the -x86 key exists.)

Resources