OmniSharp Error: Found dotnet version 5.0.201. Minimum required version is 6.0.100 - omnisharp

I use VS Code as my IDE. Today I saw in my C# files that I could no longer use things like "Go To Definition/Implementations" or hover over anything to get the path/type etc.
I found my Omnisharp console and saw they updated last night and there is an error:
Error: Found dotnet version 5.0.201. Minimum required version is 6.0.100.
I can't upgrade my dotnet because 6.0 is not compatible with the runtime in my project and on Mac M1, there are a lot of issues running multiple dotnet instances..
I guess its a bit of a rock and a hard place, anyone know how I can get around this issue?

This is a recent update to Omnisharp, which is used by the VS Code C# extension. Add this to your settings and restart the editor.
"omnisharp.useModernNet": false,
"omnisharp.path": "",
Also if you don't have Visual Studio installed you will likely need to install the Build Tools to get MSBuild:
My understanding of the rationale behind this change is an optimization for modern vanilla c# projects over those using older versions (ie Unity). More info in this issue.

Revert your Omnisharp to previous version

Update 1.25.0 introduces newer OmniSharp build for .NET 6 which does not support non SDK style .NET projects but results in performance improvements.
Fortunately you can disable this in the settings:
C# Extension Settings
Also, the C# extension no longer ships with an included Mono & MSBuild Tools. Download them here: Build Tools
Worst case, you can revert to an older extension version.

Go to extensions in VS Code and search for C# Extension
VS Code Extensions
Go to C# Extension settings
C# Extension Settings
Disable "Use Modern Net" option.
Modern Net Option
Restart VS Code

I haved similar problem and i fixed like this:
Im using win7 and i have VS 2019 IDE which not supporting dotnet 6 cuz of that vs_installer not installing dotnet6 sdk, in result i cant use c# extension v1.25.0 in vs code, because omnisharp needs net6. I installed net 6 sdk to my win7 and problem is solved, now i can use c# extension v1.25.0 in vs code.

Related

Visual Studio 2019 - Unable to debug Azure functions - (Desktop CLR (.NETFramework) versus Managed (CoreCLR)' debugger

I have installed the Visual Studio 2019 community version 16.4.4 on a brand new laptop
OS:- Windows 10 Home Single Language
The following are the .NET Core SDKS installed in my laptop
The command dotnet --info gave me the following details
I created a Azure function with V3 template
The project settings are given below
When I try to debug , i get the following error
A fatal error has occurred and debugging needs to be terminated. The debugger was configured to use the Desktop CLR (.NETFramework) Managed debugger, but the target process loaded the CoreCLR (.Net Core) runtime. To debug this project, configure it to use the 'Managed (CoreCLR)' debugger."
Tried several options like the one mentioned in the link below
https://social.msdn.microsoft.com/Forums/en-US/59f880f7-ed60-4842-bc55-a9400971c58b/problem-debugging-net-core?forum=vsdebug
EDIT: This has been fixed in the latest release of Visual Studio v16.4.5
The problem seems to be a mismatch in the version of the Azure Functions CLI. As a workaround, you can do this:
Install the latest Azure Functions CLI, from the command line run:
npm i -g azure-functions-core-tools#3 --unsafe-perm true
or if you are using Chocolatey:
choco install azure-functions-core-tools
Restart Visual Studio.
I still have this issue after reinstalling my VS2019, downloading the latest sdk and downloading the core tools multiple times. Seems like the only way for now is to run without using the debugger (Ctrl + F5). Sometimes I downgrade the function to v2.1 for this only happens on v3 functions.
Edit: I got this fixed when I updated my VS to 16.5.1
It looks like one similar issue which has been reported to DC forum. However it works well in my side with same 16.4.4 version. Since I didn't reproduce same issue, I can't provide a direct answer.
Here're some possible workarounds which may help:
Repair VS and go Tools=>Import and Export Settings=>Reset all settings=>No,just reset, overwrite... (Since my same version works well)
Hint from this one, you may backup the launchsettings.json in project and then delete it, rebuild and debug(F5) it again.
And if the issue persists, you can try installing .net core 3.0 sdk and recreate a new project to check if it helps.(I have both .net core 3.0 and 3.1 installed, but by default it picks .net core 3.0 when I create the project, not sure if it makes any difference.)
Hope it helps :)
Update:
Sorry for not noticing that the solution will not work for you. Since the solution doesn't work, you can choose another way. As the error says, you need to
configure it to use the 'Managed (CoreCLR)' debugger."
So, try to configure on hand, Select 'Debug' above the VS 2019 tab, then
Original Answer:
I faced exactly the same error before and solved it with below solution, it works well.
Solution:
Just enable the native code debuging.
Right click your project > properties > Debug. Tick ​​'enable the native code debugging' like this:
I have the same issue, I have upgraded visual studio 2019 to 16.4.4 and it resolved my issue. that was the bug by visual studio 2019 in 16.3 versions. please upgrade visual studio. it will definitely resolve your issue.
Issue was resolved with the next upgrade of Visual Studio 2019
Trying Install the v3.x Core Tools package from the command line run npm install -g azure-functions-core-tools#3.
Reference: Use npm to install Core Tools on Windows

The C# project is targeting ".NeETFramework, Version=v4.0", which is not installed on this machine

Trying to run an old project in Visual Studio 2015. It was created in 2012 or 2013, I cannot remember which. I have uninstalled both programs as I was running out of space, and i think that is what caused this. I get the following options:
And I do not want to change the target, so clicking on the second option brings me to https://www.microsoft.com/net/targeting which I can't seem to find anything there that remedies the situation. Is there a way around this without reinstalling the old version of Visual Studio again? Will that even fix my problem? Thank you.
Just Reinstall Visual Studio. When you uninstalled previous version it caused this problem.
You could try doing a repair reinstall of Visual Studio 2015.
Another point to consider is that Windows 7 (the oldest version of Windows still supported by Microsoft) includes a Windows Update for the .NET Framework v4.6.1 categorized as an "Important" update. I have not confirmed with Windows 8, but I suspect it, too, includes a similar update. Windows 10 comes with .NET 4.6 to start with. That means that any up-to-date supported machine today will be able to run apps targeting any .NET version up to and including 4.6. I recognize that there may be other reasons to continue targeting an older .NET version, but I bring this up just in case the concern is support on client workstations.

How to use newer Microsoft.CodeAnalysis reference in Roslyn analyzer targeting VS2015

Is it possible to upgrade the Microsoft.CodeAnalysis reference to something like version 1.3.x and still get the analyzer to load in VS2015?
I've got this setup working in my analyzer development environment so there seems to be some way for VS2015 to run analyzers that depend on Microsoft.CodeAnalyzer 1.3.1 for example.
However when I install the analyzer off the VSIX package to my office PC that doesn't have the VS SDKs installed VS complaisn that the extension "does not contain any analyzers". Now that I downgraded the Microsoft.CodeAnalysis references back to 1.0.0 everything works again.
How is targeting multiple VS versions supposed to work in the future in case each VS requires a reference to the same Microsoft.CodeAnalysis assembly that it uses internally?
The 1.N packages work with Update N of Visual Studio, but there is no way to use 1.3 packages with something less than Update 3.

Running ARCHICAD project in VS C++ Express 2013

I am learning archicad and trying to open an existing example from API Development Kit in VS Express C++ 2013. I have installed SDK 7.1. in order to 64 development as VS Express doesn't run it by default. I am having trouble to run the example.
However, I installed all the necessary components and programs. This error window pops up all the time I try to run. I really have no clue how to make an archicad sample project run in VS C++ Express 2013.
The third line in Russian is translated as: "Impossible to find the designated folder".
I copied the API DevKit folder into the VS Express folder, doesn't help.
Please, help if someone faced such a problem or does all this stuff.
P.S. I need to run ArchiCAD in VS C++ Express.
This is the print screen:
As a former Archicad API developer, I would definitely recommend you to use Visual Studio 2005 Express.This specific version (assuming you are developing for AC12 and above), is compatible with the API (I developed for AC13 and AC15, it worked fine). That is also recommended by Graphisoft itself.
for further information:
http://www.archicadwiki.com/Developer/Getting%20Started%20with%20the%20API%20DevKit#Getting_Started_with_the_API_DevKit
You have to check the encoding of APIdefs_Automate.h. If it is ANSI, it will fail. The encoding must be UTF-8.
For older archicad projects you had to use vs2010. For the new 21 they upgraded to vs2015. To use vs2015 in older projects you have to have vs2010 installed to use it's v100 platform toolset. Then when you open an older project with the new visual studio, it asks for upgrading the project, here say no and you are good to go.

MSBuild on CI Server can't find AL.exe

I'm having a problem on my TeamCity CI build server where during compilation I get the following error:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2342, 9): error MSB3086: Task could not find "AL.exe" using the SdkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A". Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed
I've found similar reports from a year ago when people were upgrading to .NET 3.5, for example this one. In that case, installing the latest SDK solved the issue, however I have already installed the latest SDK (Microsoft Windows SDK for Windows 7 and .NET Framework 4) on my build server. The MSBuild tools are all there on the server, in a folder called
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319
and AL.exe exists in
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools
However the registry key mentioned in the error message does not exist. So, it seems like there is something wrong with the installation/configuration of MSBuild. This error only happens for projects that have embedded resources, which require AL.exe.
As you have install the latest SDK (I'm assuming that's v7.1)
Go to "Microsoft Windows SDK v7.1" from the Start menu
Select "Windows SDK 7.1 Command Prompt" and enter
cd Setup
WindowsSdkVer -version:v7.1
This will tell msbuild to use that version of the tools without needing to do any scary registry editing.
Even though the question is quite old but it still appears in the top of google search results so I decided to post my solution as well. I have trapped into same issue while during TeamCity setup on Windows Server 2016 and Windows 10 Pro.
I have installed Microsoft Build Tools 2015 and Windows 10 SDK (Only tools for .NET 4.6.2) and got the error from question.
The missing puzzle was to set environment variable: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools.
After setting environment variable MSBuild was able to resolve all needed tools including AL.exe and build succeeded.
Please let me know if same can be achieved by setting values in registry, but otherwise environment variables also works very well in this case and no installation of VS is needed.
You also need to apply the following registry fix to update msbuild to point to the V7.1 sdk values.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0]
"MSBuildToolsPath"="C:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319\\"
"MSBuildToolsRoot"="C:\\WINDOWS\\Microsoft.NET\\Framework\\"
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1#InstallationFolder)"
"MSBuildRuntimeVersion"="4.0.30319"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDK-NetFx40Tools-x86#InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDKNetFx35Tools#InstallationFolder)"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\4.0#MSBuildToolsPath)"
I had the same problem there, here's my simple answer to this.
After you have installed the Microsoft Windows SDK 7.1 on the TeamCity Server.
In Regedit Change this key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\SDK40ToolsPath
to
$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx40Tools-x86#InstallationFolder)
Follow the below steps. This worked perfectly to me. Saved my time.
1- Right-click the My Computer icon and choose Properties, or in Windows Control Panel, choose System.
2- Choose Advanced system settings.
3- On the Advanced tab, click Environment Variables.
4- Click New to create a new environment variable under User variable section.
5- Variable name: TargetFrameworkSDKToolsDirectory
6- Variable value: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools
Variable value depends on your SDK installation path.
7- Click OK and Save all windows.
8- Restart Visual Studio.
I have a simple, effective fix.
The problem seems to be that the tools version delivered with Visual Studio is version 7.0A, while the version delivered with the Windows SDK is version 7.1. That's all very well, but MSBuild.exe is still looking for the version 7.0A registry keys, which don't exist. This has to be a bug!
Looking in my registry, all the information for V6.0 and V7.1 is present and correct. So my solution is simple. I created a registry link that makes an alias of the 7.1 keys.
It's not possible to create registry links using the built-in tools, so I downloaded a little utility called 'regln' from here.
C:>regln-x86.exe "\Registry\Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A" "\Registry
\Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1"
Job done. MSBuild now works perfectly on the TeamCity server.
Add a system env variable TargetFrameworkSDKToolsDirectory
like this:
TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools
restart VS
Ran into the same issue setting up a new build server on Windows 10.
Found and installed the latest (at the time) Microsoft Windows SDK for Windows 7 and .NET Framework 4 and that solved the problem.
We recently had this problem trying to get our .Net 4.0 builds working. We found that the location of al.exe had changed between where the original MSBuild that came with .Net 4.0 looks, and the Visual Studio SDK for .Net 4.0 (which was released later).
Since the only standalone installation of the SDK tools available is the one we had already installed without success (the one you mentioned), the only solution we could think of was to install Visual Studio on the build agents. We put Visual Studio 2010 Express (to keep the installation as lightweight as possible) on there and the problem went away. Not a pretty solution, but it did work - installing VS2010 also installs the SDK tools of the specific version that MSBuild appears to be looking for.
This is a problem that really shouldn't happen, but there didn't seem to be a way of making MSBuild look in the correct place for the tools, even hacking around in the registry.

Resources