The following line:
let system = System.create "MyActorSystem" <| Configuration.load ()
... produces this output in the F# Interactive window:
Binding session to 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Blend\Newtonsoft.Json.dll'...
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeLoadException: Could not load type 'Newtonsoft.Json.Converters.DiscriminatedUnionConverter' from assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'.
at Akka.Serialization.NewtonSoftJsonSerializer..ctor(ExtendedActorSystem system)
--- End of inner exception stack trace ---
In my project references, Newtonsoft.Json points to .\packages\Newtonsoft.Json.9.0.1\lib\net45\Newtonsoft.Json.dll. I've read that I need version 7 or above of Newtonsoft.Json for Akka.NET, so I'm not sure why I'm seeing binding for version 4.5 in the FSI output; is that a false correlation that I should just ignore?
I thought that another copy of the library file might be loading, so in C:\Program Files (x86)\Microsoft SDKs\F#\4.0\Framework\v4.0\FsiAnyCPU.exe.config, I added:
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="9.0.1.0" />
... but then I just get error FS0192: internal error: convMethodRef: could not bind to method in FSI.
I've tried looking in the fusion logs; binding succeeds for the Newtonsoft.Json library, so nothing fishy going on, there.
Anyone else run into this problem?
EDIT: OK so I discovered in the fusion logs that another copy of Newtonsoft.Json.dll, in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Blend\, was intercepting binding. How do I prevent this without simply removing the library file from the Blend folder?
I think your problem is that your not loading the Json.NET from your packages folder:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Blend\Newtonsoft.Json.dll
write at the top of the script
#I __SOURCE_DIRECTORY__
this will add the source directory on the probing paths.
your references should resolve correctly.
Related
I can't understand the warnings and errors from Visual Studio 2019. It seems that all the references to the packages of the project are no longer working after the upgrade from Visual Studio 2017.
There are the initial lines of the log when I compile the solution.
1>------ Build started: Project: ClientServerUpload, Configuration: Debug Any CPU ------
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.Text.Encoding.CodePages". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3243: No way to resolve conflict between "System.Text.Encoding.CodePages, Version=4.1.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Text.Encoding.CodePages". Choosing "System.Text.Encoding.CodePages, Version=4.1.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" arbitrarily.
1> No way to resolve conflict between "FSharp.Core, Version=4.4.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "FSharp.Core, Version=4.3.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Choosing "FSharp.Core, Version=4.4.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" arbitrarily.
1> No way to resolve conflict between "FSharp.Core, Version=4.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "FSharp.Core, Version=4.4.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Choosing "FSharp.Core, Version=4.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" arbitrarily.
1> Consider app.config remapping of assembly "FSharp.Core, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.4.3.0" [] to Version "4.7.0.0" [\\mypath\packages\FSharp.Core.4.7.0\lib\net45\FSharp.Core.dll] to solve conflict and get rid of warning.
There are many other lines after the above, but anyway I can't see what is going wrong. For example, I pick the first message, about "System.Text.Encoding.CodePages". There a warning saying "Could not locate the assembly" and another about a conflict between Version=4.1.3.0 and a reference with no version. But from where does it look at Version=4.1.3.0? In the pacakge.config there is a line:
<package id="System.Text.Encoding.CodePages" version="4.7.0" targetFramework="net461" />
and if I edit the .proj file I see:
<Reference Include="System.Text.Encoding.CodePages"> <HintPath>..\packages\System.Text.Encoding.CodePages.4.7.0\lib\net461\System.Text.Encoding.CodePages.dll</HintPath>
</Reference>
and the HintPath is indeed there. Similar doubts for all the other messages and errors.
Only another example, why is it searching FSharp.Core, Version=4.4.1.0?
Again I have
<ItemGroup>
<Reference Include="FSharp.Core">
<HintPath>..\packages\FSharp.Core.4.7.0\lib\net45\FSharp.Core.dll</HintPath>
</Reference>
in the proj file and in the packages.config
<package id="FSharp.Core" version="4.7.0" targetFramework="net461" />
All the configurations I'm aware of seem correct to me, and the whole solution was completely fine with Visual Studio 2017. The project was built with WebSharper template, I don't know if/how this is relevant, however I also reinstalled WebSharper VSIX, after upgrading to Visual Studio 2019, and I didn't receive any error.
Aside from deleting and restoring all the packages, looking at the .proj file, cleaning and rebuilding the solution, what other options do I have? At what else should I look? I know I can add remapping to the Web.config, but I don't think it is the solution (not even a workaround). For your info, after many hours I managed to get a release with many (strange) lines of remapping and by manually (!) copying some files (including FSharp.Core) from the packages to the bin folder, that is clearly not an acceptable way to proceed.
I seem to recall something similar when I upgraded an F# project from VS2015 to 2017.
The solution was to update the version of the F# runtime (FSharp.Core.dll) in the project properties.
Looking at the .fsproj for a .NET Core 3.0 F# project: the F# runtime is not actually listed, so must be an implicit dependency: maybe removing it would also work.
Step 0
I've restored an old commit of my project to better describe the original situation and to track all the steps to resolve it.
Before the following 2 operations, I had to nuget upgrade from FSharp.Core 4.6 to 4.7, for a problem specific to WebSharper: the Scripts were not produced.
Step 1
I had to edit the .proj file to delete some reference lines, sort of duplicated.
Here is an example for FSharp.Core, but I did the same for many others (I don't know what exactly originated this problem but removing those lines seems to have done the trick for me)
<Reference Include="FSharp.Core">
<HintPath>..\packages\FSharp.Core.4.7.0\lib\net45\FSharp.Core.dll</HintPath>
</Reference>
<Reference Include="FSharp.Core" />
In the above case I deleted the last line (and all the other similar lines without a version reference under a tag containing the version of the same package)
Step 2
Then I copied and pasted all the <dependentAssembly> from the Visual Studio output to the Web.config. Again I don't understand wht they are many more than the ones needed for Visual Studio 2017, but these 2 operations apparently solved my issue.
I have been developing in VS 2015 and F# 4.0 (4.4.0.0) for quite some time.
With the release of VS 2017, I want to open solutions in the newest VS for development work, but still for a while keep the projects as VS 2015, F# 4.0, .NET 4.5.2. The build server will also have to use VS 2015 for a while.
As far as I can remember, this kind of scenario has not been problematic in earlier VS version upgrades, but then I don't think I used F# at that time.
I opened the solution and tried to compile. I get this error in a C# application project. (There are other C# applications, and at least one references an F# library.)
Unknown build error, 'Cannot resolve dependency to assembly 'FSharp.Core, Version=4.4.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.
All my F# projects in the solution are 4.0 (4.4.0.0). I double checked.
Why is this happening?
I searched for "4.4.1.0", and discovered that the "obj" folder of the C# project had a .exe.config file that differed from the app.config. It had this extra information that is not in the app.config of the project.
<runtime>
...
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.4.1.0" newVersion="4.4.1.0" />
</dependentAssembly>
</assemblyBinding>
Why is this appended automatically, and why only in this particular C# project?
I tried to copy that section to the app.config of the project, and change it to 4.4.0.0 in both places, but that didn't work. Also tried to use "4.4.1.0" as upper limit of old version, and have "4.4.0.0" as new version, but still didn't work. Same compiler error.
Then I removed that section, and I referenced FSharp.Core 4.4.0.0 in the C# project. That finally got rid of the compile error.
The I ran the program. It crashed with this exception.
Unhandled exception: Could not load file or assembly 'FSharp.Core, Version=4.4.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I reinserted the section with the redirect, and now the program runs fine.
Just to sum up, I added a reference to FSharp.Core 4.0, and the redirect looks like this
<bindingRedirect oldVersion="0.0.0.0-4.4.1.0" newVersion="4.4.0.0" />
With these modifications, the solution still works as expected also in VS 2015.
I had the same problem, maybe this is helpful for someone:
In my case, the cause was that some of my C# projects with transitive dependencies on FSharp.Core were referencing the runtime's assembly installed on my system directly, instead of using the NuGet package. I.e. the reference didn't have a hint path pointing to the NuGet packages folder, and thus was picking the assembly from C:\Program Files\FSharp\... from the F# SDK. I solved this by removing the reference and reinstalling the FSharp.Core NuGet package.
So this:
<Reference Include="FSharp.Core, Version=4.3.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
Turns into:
<Reference Include="FSharp.Core, Version=4.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\..\..\packages\FSharp.Core.4.5.2\lib\net45\FSharp.Core.dll</HintPath>
<Private>True</Private>
</Reference>
Check the assembly references of the assembly in the message. For me I had a reference to assembly X which had a reference to Y. Because Y was missing, I got this error. By referencing Y, the error was resolved for me.
I'm trying to setup a basic FAKE F# project that can run FsUnit but I cannot figure out how to solve the Method not found: 'Void FsUnit.TopLevelOperators.should(Microsoft.FSharp.Core.FSharpFunc`2<!!0,!!1>, !!0, System.Object)' errors.
I have read the following posts that seem to be related, but I'm apparently still not grokking it:
Main github issue
FSharp.Core packaging guidelines
FsUnit unable to test portable library (SO)
Another github issue
I have created a JunkTest library project with the following setup:
paket.dependencies
source https://www.nuget.org/api/v2
nuget FAKE
nuget FSharp.Core
nuget FsUnit
nuget NUnit
nuget NUnit.Console
paket.references
FSharp.Core
FsUnit
NUnit
JunkTest.fs
module JunkTest
open FsUnit
open NUnit.Framework
[<Test>]
let ``Example Test`` () =
1 |> should equal 1 // this does not work
//Assert.That(1, Is.EqualTo(1)) // this works (NUnit)
build.fsx (relevant part)
Target "Test" (fun _ ->
!! (buildDir + "JunkTest.dll")
|> NUnit3 (fun p ->
{p with OutputDir = "TestResults" }
)
)
Output
I see that FSharp.Core.dll is being copied from the local packages directory: Copying file from "c:\Users\dangets\code\exercism\fsharp\dgt\packages\FSharp.Core\lib\net40\FSharp.Core.dll" to "c:\Users\dangets\code\exercism\fsharp\dgt\build\FSharp.Core.dll".
And the nunit3-console execution: c:\Users\dangets\code\exercism\fsharp\dgt\packages\NUnit.ConsoleRunner\tools\nunit3-console.exe "--noheader" "--output=TestResults" "c:\Users\dangets\code\exercism\fsharp\dgt\build\JunkTest.dll"
I have tried to add a app.config file with the in the test project root directory with the following but it doesn't seem to solve the issue (NOTE I am not using Visual Studio - do I need to do anything special for the project to include the app.config file?):
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.3.1.0" newVersion="4.3.1.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Any and all help is appreciated.
EDIT: The solution was that I was not properly setting up the App.config file to get included in the build. All of the answers that said "just add this to your App.config file" didn't help me because VSCode doesn't add this to the fsproj file automatically.
The part that I added is:
<None Include="App.config" />
In the ItemGroup that contains the other <Compile Include=Foo.fs> lines.
This happens because of FSharp.Core version mismatch. See, your application references one version of FSharp.Core and FsUnit references another version. This means that the FSharpFunc<_,_> type is going to be different (coming from different assemblies) for you and FsUnit, which in turn means that the should function exported by FsUnit is not the same function that your code is looking for, because it has a parameter of a different type.
This is where the bindingRedirect comes in. You're absolutely correctly added it to app.config, but from your question about whether you're doing it correctly, I get a suspicion that you might not. The thing with app.config is, it's not actually the program configuration. Rather, it's the source code for program configuration. At compile time, this file gets copied to bin\Debug\Your.Project.dll.config, and only then it will get picked up at runtime. If you didn't add this file to the fsproj project file (which, I suspect, might be the case), then it's not getting copied to the right place during build, and thus isn't getting picked up at runtime.
Another reason for it still not working may be that you've specified an incorrect version of FSharp.Core in your app.config file. Which brings me to the next point.
Crafting that file by hand is a bit fragile: when you upgrade FSharp.Core to a new version (or Paket does it for you), you may forget to fix it in app.config and even if you don't, it's a bit of a hassle. But Paket can help you with that: if you add the redirects: on options to your paket.dependencies file, Paket will add the bindingRedirect cruft to your app.config automatically:
source https://www.nuget.org/api/v2
nuget FAKE
nuget FSharp.Core redirects: on
nuget FsUnit
nuget NUnit
nuget NUnit.Console
This sounds like an FSharp.Core version mismatch.
The NuGet package you're using ships with FSharp.Core 4.4 (not 4.3.1). I recommend modifying your binding redirect to use 4.4:
<bindingRedirect oldVersion="0.0.0.0-4.3.1.0" newVersion="4.4.0.0" />
Attempting to run the MVC 5.2 project, which is built successfuly, got the following error:
An exception of type 'System.IO.FileLoadException' occurred in
ProjectNamespace.WebUI.dll but was not handled in user code
Additional information: Could not load file or assembly 'Autofac,
Version=3.4.0.0, Culture=neutral, PublicKeyToken=17863af14b0044da' or
one of its dependencies. The located assembly's manifest definition
does not match the assembly reference. (Exception from HRESULT:
0x80131040)
Assembly manager loaded from:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Running under
executable C:\Program Files (x86)\IIS Express\iisexpress.exe
--- A detailed error log follows.
=== Pre-bind state information === LOG: DisplayName = Autofac, Version=3.4.0.0, Culture=neutral, PublicKeyToken=17863af14b0044da
(Fully-specified) LOG: Appbase = file:///C:/ProjectPath/WebUI/ LOG:
Initial PrivatePath = C:\ProjectPath\WebUI\bin Calling assembly :
Autofac.Integration.Mvc, Version=3.3.0.0, Culture=neutral,
PublicKeyToken=17863af14b0044da.
=== LOG: This bind starts in default load context. LOG: No application configuration file found. LOG: Using host configuration file:
C:\Users\me\Documents\IISExpress\config\aspnet.config LOG: Using
machine configuration file from
C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Autofac, Version=3.4.0.0, Culture=neutral,
PublicKeyToken=17863af14b0044da LOG: Attempting download of new URL
file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary
ASP.NET Files/root/5c8bedab/6a36492/Autofac.DLL. LOG: Attempting
download of new URL
file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary
ASP.NET Files/root/5c8bedab/6a36492/Autofac/Autofac.DLL. LOG:
Attempting download of new URL
file:///C:/ProjectPath/WebUI/bin/Autofac.DLL. WRN: Comparing the
assembly name resulted in the mismatch: Minor Version ERR: Failed to
complete setup of assembly (hr = 0x80131040). Probing terminated.
My web.config has the following settings:
<dependentAssembly>
<assemblyIdentity name="Autofac" publicKeyToken="17863af14b0044da" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.5.0.0" newVersion="3.5.0.0" />
</dependentAssembly>
Spent hours trying to resolve it, but failed. Please help.
This problem has become quite common. It seems to come up when you have the Autofac, Autofac.Mvc5 and Microsoft.AspNet.Mvc>5.1.0 packages, even though Autofac.Mvc5 is stated to work with Microsoft.AspNet.Mvc(≥ 5.1.0 && < 6.0.0).
I suggest the classic solution of checking and adding the appropriate assembly binding redirects for autofac, not only in the project which references it but in projects referencing that project as well.
Another potential problem is having two entries for the
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
in your config, if you have your bindings in the second one move them to the first one. That fixed it for me in a situation where I was also encrypting some configuration settings and for some reason the binding redirects were not copied into the resulting config file.
I highly recommend the Assembly Binding Log Viewer, it helped me a lot in figuring out the issue, even though my final solution was a cowardly one, going to Autofac3.4.0.0 and Microsoft.AspNet.Mvc 5.1.0. I spent way too much time on fixing the problem.
Also, for those who are interested you can use the nuget manager to detect and fill in your assembly binding redirects: Get-Project -All | Add-BindingRedirect (from here). It might need some additions afterwards depending on your porjects and references but at least it's going to give you a clean slate to begin with.
Update
Microsoft.AspNet.Mvc 5.2.3 was released so I decided to try again. I updated every package involved in the "conflict" to the latest version (Autofac 3.5.2, Autofac.Mvc5 3.3.4, Microsoft.AspNet.Mvc 5.2.3). I updated the redirect bindings and it worked.
When I checked in the code, TFS 2013 built the solution automatically. It is okay in local VS 2013 but failed in TFS.
Here is the summary.
Summary
FTPProcessor | Any CPU
1 error(s), 56 warning(s)
$/xxxx/NewServiceHost/New-Branch/NewServiceHost/packageRestore.proj - 0 error(s), 0 warning(s)
$/xxxx/NewServiceHost/New-Branch/GenericWindowsServices.sln - 1 error(s), 56 warning(s)
C:\Builds\1\xxxx\FTP Processor (New)\src\.nuget\nuget.targets (71): The task factory "CodeTaskFactory" could not be loaded from the assembly "C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Build.Tasks.v4.0.dll". Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Build.Tasks.v4.0.dll' or one of its dependencies. The system cannot find the file specified.
Other Errors
1 error(s)
Exception Message: MSBuild error 1 has ended this build. You can find more specific information about the cause of this error in above messages. (type BuildProcessTerminateException) Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
Your TFS 2013 build server is using MSBuild 12.0 where CodeTasksFactory exists in Microsoft.Build.Tasks.v12.0.dll rather than Microsoft.Build.Tasks.v4.0.dll.
Ideally you should be doing the following:
1) Open your NuGet.targets file:
C:\Builds\1\xxxx\FTP Processor (New)\src.nuget\nuget.targets
2) Identify the task referencing the old DLL.
<UsingTask AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" TaskFactory="CodeTaskFactory" >
...
3) Then future proof it like so:
<UsingTask AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v$(MSBuildToolsVersion).dll" TaskFactory="CodeTaskFactory" >
...
As of VS2013,
you should be running MSBuild from C:\Program Files (x86)\MSBuild\12.0\Bin\
not from C:\Windows\Microsoft.NET\Framework64\v4.0.30319. See
http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx
source:http://gyorgybalassy.wordpress.com/2013/12/31/msb4175-the-task-factory-codetaskfactory-could-not-be-loaded/
it solved the issue for me.
After much research and trying a bunch of "hacks" I went on to understand the exact mechanics of nuget restore. It turns out, everything has changed since nuget 2.7+ and you're no longer required to include ".nuget" folder and the associated nuget.exe and nuget.target
To fix my build process and use the latest recommended approach, I did the following:
Move nuget.config to be with .sln file same folder path
Delete ".nuget" folder entirely
Delete references to that folder in .sln file
Delete following lines from any .csproj file
--
<RestorePackages>true</RestorePackages>
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />
--
This could take some time if your project solution has many files or you work on many projects built with Visual Studio 2013 and before.
The good news is, there's a powershell script that applies the above recursively on any folder:
https://github.com/owen2/AutomaticPackageRestoreMigrationScript/blob/master/migrateToAutomaticPackageRestore.ps1
In short, it reverses "Enable Nuget Package Restore", allowing the
newer package restore method to work.
In Visual Studio 2013, automatic package restore became part of the
IDE (and the TFS build process). This method is more reliable than the
older, msbuild integrated package restore. It does not require you to
have nuget.exe checked in to each solution and does not require any
additional msbuild targets. However, if you have the files related to
the old package restore method in your project, Visual Studio will
skip automatic package restore. (This behavior is likely to change
soon, hopefully it does).
You can use this script to remove nuget.exe, nuget.targets, and all
project and solution references to nuget.targets so you can take
advantage of Automatic Package Restore. It more or less automates the
process described here.
It will recurse through the directory you run the script from and do
it to any solutions that may be in there somewhere. Be careful and
have fun! (not responsible for anything that breaks)
A couple of good links on the subject:
http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html
http://docs.nuget.org/consume/package-restore/migrating-to-automatic-package-restore
I had a similar issue. We are forced into using the older msbuild that comes with the framework, rather than the v14 version that comes with visual studio 2015 because we build some old Delphi.net code. Our vcxproj files are triggering some automatic code analysis target which has a task that relies on Microsoft.Build.Tasks.v12.0.dll. I was able to override that task by copying and pasting it into the top of the vcxproj and tweaking the path to the dll. The original task can be found in "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeAnalysis\Microsoft.CodeAnalysis.Targets". So, in other words, you might be able to override the problem task in your project.
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- override a task which we can't use with the old msbuild -->
<UsingTask TaskName="SetEnvironmentVariable" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll">
<ParameterGroup>
<EnvKey ParameterType="System.String" Required="true" />
<EnvValue ParameterType="System.String" Required="true" />
</ParameterGroup>
<Task>
<Using Namespace="System" />
<Code Type="Fragment" Language="cs">
<![CDATA[
try {
Environment.SetEnvironmentVariable(EnvKey, EnvValue, System.EnvironmentVariableTarget.Process);
}
catch {
}
]]>
</Code>
</Task>
</UsingTask>