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.
Related
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.
The official documentation does not work.
Do I need VS 2017 Preview?! Or to restart my pc every time I install "Latest stable 2.2.3" SDK's? Perhaps its not so stable? Should I try 2.2.1 lol
VS 2015 will work up for up to .NET Core 1.1 (now EOL). VS 2017 will work for up to .NET Core 2.2. .NET Core 3.0+ requires VS 2019.
It's not clear what your exact issue is, but the process is basically this:
Download the appropriate .NET Core SDK version. Be careful because the SDK version is somewhat independent of the .NET Core version. Pay attention to specifically what version of .NET Core the SDK supports, not the version number of the SDK itself.
Edit your project file and change the target to the new .NET Core version. This will be the minor version, not patch releates. In other words, for any .NET Core 2.2.X, you'd use netcoreapp2.2 as your target.
That's it. After you save, any NuGet dependencies of your project, such as Microsoft.AspNetCore.App will update to the latest version within that target, i.e. 2.2.X. However, note that some packages may not always have new versions. Most of the major parts of ASP.NET Core, for example, change enough with each version that the NuGet packages get bumped as well. However, it is possible that you may still use a 2.1.X package if nothing changed in that for 2.2. In any case, you'll be able to see in Visual Studio if it's fully updated or not.
I've retargeted my C++/CX UWP project to the latest Windows version (10.0.10586) available to me. However, under references, the Windows.Foundation.UniversalApiContract version shows 2.0.0.0, the latest is 3.0.0.0 introduced in 10.0.14393.0. I need to use the features in 3.0.0.0, but I can't figure out for the life of me how to use it. I've looked through the .vcxproj, and the appxmanifest and I can't find anything relevant. There's nothing I can find in the GUI either. How do I change the version?
You can set the target version in the project properties.
In the Project Properties editor it's in the config tab's Target Platform Version:
In the vcproj it's the WindowsTargetPlatformVersion:
<WindowsTargetPlatformVersion>10.0.14393.0</WindowsTargetPlatformVersion>
<WindowsTargetPlatformMinVersion>10.0.10586.0</WindowsTargetPlatformMinVersion>
You'll need to have the 14393 SDK installed from https://developer.microsoft.com/en-US/windows/downloads/windows-10-sdk . If Visual Studio thinks 10586 is the latest then you probably don't have the updated SDK. You should also make sure you have the latest update to Visual Studio (2015 Update 3 or 2017 RC)
I am using Visual Studio 2015 (Pre), Framework 4.5.2
I have the folowing project structure
StorageProject
nuget package Microsoft.WidowsAzure.Storage is installed
This Nuget package has (among others) dependencies on Microsoft.Data.OData, wich is also installed
AnotherProject
Has a refernce on StorageProject
Does not have any nuget package or other refernces (except default references on the framework)
Here is the list of the packages installed in StorageProject
WindowsAzure.Storage 4.3.0
Microsoft.WindowsAzure.ConfigurationManager 3.1.0
System.Spatial 4.3.0
Microsoft.Data.Edm 5.6.4
Microsoft.Data.OData 5.6.4
Microsoft.Data.Services.Client 5.6.4
These are all dependencies of WindowsAzure.Storage, latest versions.
There is no other version of these packages installed anywhere on the solution.
I will focus on Microsoft.Data.OData, but the same problem occurs with Microsoft.Data.Edm and Microsoft.Data.Services.Client 5.6.4
When building StorageProject, the correct version of these dll (5.6.4) ends up in the bin folder of the project.
But when building AnotherProject, the bin folder contains version 5.6.2 of the dll.
Now I passed all day trying to figure out where these dlls come from.
There is a version 5.0.0.0 in the GAC, wich I cannot uninstall. (gacutil yields it is used by something).
I did a file search on C:\ to find that the only place where this version of the dll is (beside the bin folder of my project) is in C:\Program Files (x86)\Microsoft WCF Data Services\5.6.2. If I delete (move) this folder, my project builds "normally" and everything is fine. In fact, in this case OData is not in the bin folder at all. And as far as I am concerned, that's ok this way.
Now the real question(s) :
Why is it the version from Microsoft WCF Data Services that ends up in the bin, instead of the version actually installed in the referenced project?
Where does Microsoft WCF Data Services comes from ? I don't remember installing it at all, maybe it comes with a version on Visual Studio? (I have 2012, 2013 and 2015 installed)
Can I uninstall it? I don't see it in Windows' control panel.
•Why is it the version from Microsoft WCF Data Services that ends up in the bin, instead of the version actually installed in the referenced project?
This could be due to the fact that the storage client does not depend on a specific version of the Data Service Client. Since Specific Version is set to false, the GAC will be searched first during compilation, any version will be considered "acceptable", and no other version will be exported.
•Where does Microsoft WCF Data Services comes from ? I don't remember installing it at all, maybe it comes with a version on Visual Studio? (I have 2012, 2013 and 2015 installed)
It could be installed due to a variety of reasons. The Azure SDK contains this as well. So if you ever installed the Azure SDK, it could have come with that.
•Can I uninstall it? I don't see it in Windows' control panel.
Looks like this is only possible by uninstalling the MSI package that installed the assembly via Add/Remove programs. For that, you would have to again figure out which installation brought this assembly with it and check whether that is needed or not.
I will try to explain this as clear as I can
I want to fully understand how MSBuild multitargeting works.
I have read several articles from Microsoft and I think I understand the basic but I want to be sure I am not missing anything.
According to Microsoft:
By using Visual Studio, you can compile an application to run on any one of several versions of the .NET Framework. For example, you can compile an application to run on the .NET Framework version 2.0, and compile the same application to run on the .NET Framework version 4. The ability to compile to more than one framework is named multitargeting.
Visual Studio runs under the most current version of the .NET Framework that is installed on the development computer.
http://msdn.microsoft.com/en-us/library/ee395432.aspx
So do this mean that Visual Studio always calls MSBuild from the latest framework installed? assuming Visual Studio 2010 is installed, it will always call: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe when building any project targettting any .Net Framework version right???
If yes, then the ability to target old .Net Framewrok versions is based on the ToolsVersion and/or TargetFrameworkVersion properties right???
If yes again, it would mean that just installing the latest framework (and also the older frameworks but not installing visual studio) in my Continuous Integration box, I could point to build always any solution to: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe and just specify the ToolsVersion argument (if required, since each project can have its own target version specified in the TargetFrameworkVersion which it would cause to target an older .Net Framework version).
Following this I think my CI box would be building like Visual Studio does. Am I right? What am I missing? Is there a way to be completely sure?
I did a quick test, and I think it works :p the projects are being built according to the .Net Framework specified but like I said I want to be sure I am not missing anything.
Any thoughts?
BTW:
The simple reason to want to do that is because I have several custom MSBuild scripts that are reusable accross projects, but some of the functionality in these scripts require MSBuild 4.0 and also I have several MSBuild tasks built on top of the framework 4.0 so if I have for example a solution targetting the Framework 2.0 and I try to build it using: %WINDIR%\Microsoft.NET\Framework\v2.0.50727\MsBuild.exe I get MSBuild errors trying to load my custom targets
Yes, you've got it mostly correct. Calling MSBuild from the 4.0 directory will do the correct thing against previous versions. They only thing I wanted to add was that 3.5 must be on the box to actually build projects targeting 2.0, 3.0 and 3.5.
This page here: http://msdn.microsoft.com/en-us/library/bb822049.aspx calls out the what versions Windows comes with what version of the framework pre-installed.