We Keep Coding

Path.GetDirectoryName changes in .NET Framework 4.6.2

Recently I updated my unit test project from .NET 4.5.1 to a higher version. When you update .net to 4.6.2 and higher there are changes in Path.GetDirectoryName behavior. It is known that in 4.6.2 version it become stricter, not allowing uri syntax anymore. But in my case I observe that it becomes LESS strict in some cases. The wrong path "/:\test\temp.txt" which caused an exception before now passes. Is this also a known issue or are there reasons for it?
using System.IO;
...
string dir = Path.GetDirectoryName("/:\\test\\temp.txt");
// .net 4.6.1: throws ArgumentException: The path is not of a legal form.
// .net 4.6.2 and above: dir = \:\test

Retargeting All Projects in a Solution to .NET 4.5.2

I have a solution in Visual Studio 2012 with 170 C# projects in it. I need to retarget all of the projects from .NET Framework 4.0 to 4.5.2.
I prefer to let Visual Studio handle this by going into the properties of each project, changing the targeted framework, and letting Visual Studio make any necessary changes to the .csproj files.
I noticed that these changes include adding a few new XML tags to the .csproj, depending on some attributes of the current project.
How can I batch retarget all 170 C# projects without just using a replace text tool to replace the targeted version number? I want Visual Studio to make all the necessary tag modifications and additions and replace alone will not permit that to happen.

The MSDN documentation "Migration Guide to the .NET Framework 4.5" and "How to Configure an App to Support .NET Framework 4 or 4.5" only discusses modifying projects. There's no details on applying changes to the entire solution at once, nor have I seen a function in VS that supports it.
However, there's a (well-rated) extension called Target Framework Migrator available in the Visual Studio gallery, which supports upgrading to 4.5.2 (as well as newer versions**) and looks like it'll do exactly what you want. The source code is available on GitHub, if you're interested.
Note that the lack of such a feature may be intentional (and not just an omission). I'm just guessing, but maybe MS figures only projects that need the new Frameworks will be upgraded. FWIW, if you end up upgrading some projects that are shared with other solutions, those solutions may fail to build until they're upgraded too.
That being said, if you're in a small shop with just one (or a few) solutions and you're looking to upgrade everything in one go, then perhaps the above tool will work for you.
There's been no development on this for years, and apparently the developer has no plans to pass the baton to anyone else.
If you're unable to get it to work with a newer .NET Framework version, check the existing PRs and Issues for fixes, but you may have to apply them yourself. For example, someone posted a fix for .NET Framework v 4.7.1. Hopefully these will get merged, but I wouldn't hold my breath.
If anyone else is seeing the same error as Anas (in the comments), here's a GitHub issue from a couple weeks ago, and another possibly related issue from 2017. Consider thumbs upping them and adding more details if you're having the same problem.

For a .NET Framework solution, a simple "Replace in files" did the trick for me:
eg: From .NET Framework 4.5.2 to .NET Framework 4.7.2
In package.config files, replace all
targetFramework="net452"
to
targetFramework="net472"
In *.csproj files, replace all
<TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
to
<TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>

Since the Target Framework Migrator is broken, I rolled my own search/replace (using git bash, it works ok on windows) ; Basically it changes the v4.6.x into v4.7.2, then it converts back the files to using the infamous DOS's CRLF :
find . \( -iname '*.csproj' -o -iname '*.vcxproj' -o -iname 'app.config' \) \
-exec grep -Z -l 'v4\.6\..' \{} \; | xargs -0 sed -i 's/v4\.6\../v4.7.2/'
find . \( -iname '*.csproj' -o -iname '*.vcxproj' -o -iname 'app.config' \) \
-exec grep -Z -l 'v4\.7\..' \{} \; | xargs -0 unix2dos

I have built myself a simple tool to migrate the target framework versions for an entire solution, because the Target Framework Migrator Extension does not support Visual Studio 2017. Download the tool from my GitHub repository https://github.com/Xpitfire/TargetFrameworkMigrator
I know this is not the best way to go, but it worked for me and maybe it will also help someone else.

Target Framework Migrator is pretty useful. By default, it comes up to v4.7. However, it's easy to add support for v4.7.1, v4.7.2 and v4.8.
Find Frameworks.xml file in C:\Users{username}\AppData\Local\Microsoft\VisualStudio\ folder and edit by adding these framework versions:
<Framework Id="262152" Name=".NETFramework,Version=v4.8"/>
<Framework Id="262663" Name=".NETFramework,Version=v4.7.2"/>
<Framework Id="262407" Name=".NETFramework,Version=v4.7.1"/>
After you restart visual studio, you will see new versions.

public void ChangeFramework() {
//Add Reference to envdte (Assemblies\Extensions\envDTE)
string SolutionFile = #"C:\MyProject\MyProject.sln";
string ProjectName = "MyProject";
//------------------------------------------------------------------------
//Find the Program ID from the registry for VisualStudio.DTE
//Look it up In Registry: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes
System.Type oType = System.Type.GetTypeFromProgID("VisualStudio.DTE", true);
EnvDTE.DTE dte = (EnvDTE.DTE)Activator.CreateInstance(oType, true);
//------------------------------------------------------------------------
//Open your Solution
dte.Solution.Open(SolutionFile);
//------------------------------------------------------------------------
//Now In your solution go through what is listed in dte.Solution.Projects
//and find the one that match what you want to change target for
int iItemsCount = dte.Solution.Projects.Count;
string sCurrent = "";
for (int i = 1; i <= iItemsCount; i++) {
sCurrent = dte.Solution.Projects.Item(i).Name;
if (dte.Solution.Projects.Item(i).Name == ProjectName) {
//Once you find your project, Change the Framework
EnvDTE.Project oProject = dte.Solution.Projects.Item(i);
oProject.Properties.Item("TargetFrameworkMoniker").Value = ".NETFramework,Version = v4.6.2";
}
}
//------------------------------------------------------------------------
//Close your Solution
dte.Solution.Close();
}

Library .NET version exception [duplicate]

This question already has answers here:
What 'additional configuration' is necessary to reference a .NET 2.0 mixed mode assembly in a .NET 4.0 project?
(17 answers)
Closed 8 years ago.
Im trying do my first steps in Winforms development with C# and .NET framework.
I want to make a little users CRUD application. I have the SQLite db populated with test data.
So, i create a blank project solution, and added a "Class library" project called "DataBundle".
In the DataBundle, have the entity class for the database, mapped with Entity Framework.
Also, i created a console application for test my DataBundle. The app build correctlly, but when try run querys the application throw an exception.
This is my code:
Console.WriteLine("Testeando el DataBudnle ...");
mainContext _dao = new mainContext();
Zone city = new Zone
{
name = "Ensenada"
};
Console.WriteLine("Existen {0} ciudades registradas ...", _dao.Zones.Count());
Console.ReadLine();
And the exception message is:
The mixed-mode assembly is compiled with 'v2.0.50727' version of the
runtime and can not be loaded in the 4.0 runtime without additional
configuration information.
Im using Visual Studio 2010 Ultimate, Windows 7 Professional with .NET 4 Framework installed.
Any ideas ?

As Steve suggested there, add this in the console application App.config file
<?xml version="1.0"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
</configuration>

Call a specific version of PowerShell from C#

I'm trying to use the Get-VM Cmdlet called from C# on a Hyper-V host.
Obviously, the according PowerShell module Hyper-V has to be imported first. The import fails, however - apparently because the module is supported only on PowerShell 3.0 (at least that's what I figure from this article). The PowerShell used by System.Management.Automation seems to be version 2.0, though.
InitialSessionState iss = InitialSessionState.CreateDefault();
iss.ImportPSModule(new string[] { "Hyper-V" });
Runspace runSpace = RunspaceFactory.CreateRunspace(iss);
runSpace.Open();
foreach (var err in (ArrayList)runSpace
.SessionStateProxy.PSVariable.GetValue("Error"))
Console.WriteLine(err.ToString());
runSpace.Close();
returns
The
'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Hyper-V\Hyper-V.psd1'
module cannot be imported because its manifest contains one or more members
that are not valid. The valid manifest members are ('ModuleToProcess', ...).
Remove the members that are not valid ('HelpInfoUri'),
then try to import the module again.
Is there a way to use a specific version of PowerShell in C#?

A colleague figured it out:
Apparently, .NET 4+ comes with an all new common language runtime: the CLR4
This runtime uses its own assemblies loaded from a new assembly cache located at C:\Windows\Microsoft.NET\assembly.
The System.Management.Automation version 3.0.0.0, which will automatically use PowerShell 3.0, exists for the CLR4 only. Because I configured my application to run under .NET 3.5, it would use the old CLR2 and could not even see the newer assembly.
To make sure the application would still run on .NET 3.5, add this to the App.config file in the project folder:
<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>
If CLR4 is available, it'll load the according GAC, find a policy file that redirects all references to System.Management.Automation version 1.0.0.0 to version 3.0.0.0 and the PowerShell-Modules work as expected.
If you only have .NET 3.5, the older version will be loaded; PowerShell still works, but only up to version 2.0.

Have you looked at this yet?
http://code.msdn.microsoft.com/windowsdesktop/Windows-PowerShell-30-SDK-9a34641d
You might just need the new SDK to call Powershell 3 even if PSv3 is installed on your system already, but I'm usually just a straight Powershell guy.

Looks like MSVS 11.0 Beta spoiled a MSVS 10.0 installation

I ran into compilation problems with my MSVS 10 after installing MSVS 11Beta. Now, when I compile my C# Projects in MSVS 10 (Projects created in MSVS 10; Target framework: 3.5), I get errors MSB4216, MSB4028 with following text in output window:
1>Task "GenerateResource" skipped, due to false condition; ('%(EmbeddedResource.Type)' == 'Resx' and '%(EmbeddedResource.GenerateResource)' != 'false' and '$(GenerateResourceMSBuildRuntime)' != 'CLR2') was evaluated as ('Resx' == 'Resx' and '' != 'false' and 'CLR2' != 'CLR2').
1>Task "GenerateResource"
1> Launching task "GenerateResource" from assembly "Microsoft.Build.Tasks.v3.5, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" in an external task host with a runtime of "CLR2" and a process architecture of "x86".
1>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2199,5): error MSB4216: Could not run the "GenerateResource" task because we could not create or connect to a task host with runtime "CLR2" and architecture "x86". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NetFX 4.0 Tools\MSBuildTaskHost.exe" exists.
1>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2217,7): error MSB4028: The "GenerateResource" task's outputs could not be retrieved from the "FilesWritten" parameter. Object does not match target type.
1>Done executing task "GenerateResource" -- FAILED.
How can I fix these errors?
EDIT:
Mentioned file "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NetFX 4.0 Tools\MSBuildTaskHost.exe" exists.
C++ projects are compling without problems.
Reinstalling VS10 doesn't solve the problem.
This is GenerateResource task, that must compile resx-file, but generates an exception:
<!-- But we can't use those parameters if we're targeting 3.5, since we're using the 3.5 task -->
<GenerateResource
Sources="#(EmbeddedResource)"
UseSourcePath="$(UseSourcePath)"
References="#(ReferencePath)"
AdditionalInputs="$(MSBuildAllProjects)"
NeverLockTypeAssemblies="$(GenerateResourceNeverLockTypeAssemblies)"
StateFile="$(IntermediateOutputPath)$(MSBuildProjectFile).GenerateResource.Cache"
StronglyTypedClassName="%(EmbeddedResource.StronglyTypedClassName)"
StronglyTypedFileName="%(EmbeddedResource.StronglyTypedFileName)"
StronglyTypedLanguage="%(EmbeddedResource.StronglyTypedLanguage)"
StronglyTypedNamespace="%(EmbeddedResource.StronglyTypedNamespace)"
StronglyTypedManifestPrefix="%(EmbeddedResource.StronglyTypedManifestPrefix)"
PublicClass="%(EmbeddedResource.PublicClass)"
OutputResources="#(EmbeddedResource->'$(IntermediateOutputPath)%(ManifestResourceName).resources')"
MSBuildRuntime="$(GenerateResourceMSBuildRuntime)"
MSBuildArchitecture="$(GenerateResourceMSBuildArchitecture)"
Condition="'%(EmbeddedResource.Type)' == 'Resx' and '%(EmbeddedResource.GenerateResource)' != 'false' and '$(GenerateResourceMSBuildRuntime)' == 'CLR2'">
I tried to debug MSBuild script (.csproj). Just before the fatal GenerateResource task I checked all the properties and items. There was nothing about "8.0A" but only about "7.0A"

There is an ugly way to fix the problem: renaming folder "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A". I hate to accept this answer.

How long is your username?
It seems that there is a bug when the username is 20 characters long. If your username is 19 characters or less it works fine.
I have opened an issue on connect.
Edit:
Have you tried setting the environment variable DisableOutOfProcTaskHost to true as suggested in the connect issue, that worked for me.

A similar questin was asked on the MSDN forums. Did you reboot after installing VS11?
http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/7d955d96-ff73-47d3-8830-85ea321eb4ab

This issue occurred for me on my TFS 2010 build server after installing VS2010 and then installing .NET Framework 4.5. This allowed me to build .NET 4.5 projects but any VS2008 project targeting CLR2 (.NET 2.0 -3.5) I attempted to build would return the error. None of the suggestions on the handful of sites talking about this issue worked.
Rebooting - Did not fix the issue
Setting DisableOutOfProcTaskHost = true in an environment variable and also within the project file - Did not fix the issue
Username of my build account was already less than 20 characters
Renaming windows SDK folder - N/A since I did not have VS2012 and the 8.0A SDK installed... just .NET framework 4.5.
In any case, to fix this I uninstalled .NET 4.5, repaired VS2010, and then rebooted the build server. Now I am able to build VS2008 and VS2010 projects with no issues.
Luckily I no longer need to build .NET 4.5 projects as that team decided to go back to .NET 4.0.

Another possible fix is to change the target framework of your projects to .Net 4.0. It's not always a solution, but it certainly is a possibility if all else fails.

Worked for me: Removing the bin and obj folder for problematic folders and restarting the solution

In my case, I received that error message when trying to build a solution on a 32-bit Windows 7 machine. The way to resolve the error for me was to right-click on the project, choose properties, then go to the Build tab. In here I changed the "Platform target" from "Any CPU" to "x86". HTH

Setting Setting DisableOutOfProcTaskHost = true in an environment variable worked for me.