Cannot build a binary module referencing 3.0 SMA.dll on Windows 10 without having to retarget to .NET 4.5
Votes from Connect: 5
Original Date Submitted: 9/21/2015 7:09:45 AM
Handle: Keith Hill MVP
Site Name: PowerShell
Feedback ID: 1816181
Regression: Try to build a binary module on Windows 10 RTM with VS 2015. Reference the 3.0 SMA.dll reference assembly. This will fail to compile.
When I try to build PSCX on Windows 10 - referencing System.Management.Automation.dll version 3.0 in the C:\Program Files (x86)\Reference Assemblies folder, I get a build error in VS 2015:
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3275: The primary reference "System.Management.Automation, Version=22.214.171.124, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the assembly "Microsoft.Management.Infrastructure.Native, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31bf3856ad364e35" which was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client".
The only way I could work around this is to retarget to .NET 4.5 but I suspect that means my module won't work on Windows 7 system that are still running .NET 4.0.
Product Studio item created by Connect Synchronizer due to creation of feedback ID 1816181 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1816181).
Try to build a binary module on Windows 10 RTM with VS 2015. Reference the 3.0 SMA.dll reference assembly. This will fail to compile.
I would have expected Microsoft.Management.Infrastructure.Native 188.8.131.52 not to have jumped from .NET 4.0 to 4.5. I can see having a 184.108.40.206 that uses 4.5 that lives side-by-side with 220.127.116.11 that still uses .NET 4.0.
Internal BugId: 15832
https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/33338296-bug-binary-module-loading-fails-silently-on-fall may be related - and now has a workaround using a policy config file (more specifically, a registry entry that points Fusion at a policy file). Following the chain of references from https://github.com/aspnet/Tooling/issues/755 may (or may not) provide other helpful hints.