My question is the opposite of just about every question I have found online.
I want to enable C# 7.0 warnings/errors in Resharper (running in VS2017, release just installed today.)
I need to do this because the project I am working on will be published to my workplace's server, and their CI throws fatal errors when C# 7.0 features are used (R# C# 7.0 language feature), so I can't use them (they won't accept any project that fails fatally with their CI.)
They're using Resharper CLI in the CI. So I want to make my Resharper throw the same errors, so I can quickly locate and eliminate C# 7.0 features. My Resharper shows the project as being clean (other than some minor "it might be a problem but it's not for me" things), so I have no fatal errors or even warnings about C# 7.0 when I run a code analysis.
Every question I have seen so far is asking about how to disable warnings about C# 7.0. My Resharper is not throwing any warnings or errors, while the one on our CI is.
I've looked through the options but can't find any obvious "C# 7.0" options. I've looked for something like "maximum supported language/throw an error if language feature in later version is used/etc" but I can't seem to find anything.
Edit: Web.config codedom section:
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701" />
</compilers>
</system.codedom>
It's definitely set to language version 6...
You can configure which C# version the build engine uses for each project by right clicking on the project, select Properties, Select the Build section, click on Advanced..., set Language version to whichever version your CI server works with. Once you do this the build will fail when you build locally on any C#7.0 features.
Alternately you could try to get your CI server upgraded to work with C#7.0.
The Resharper language rules and Studio rules lie in different places.
Studio (and Roslyn) rules you can find in project settings.
Resharper keeps warning rules in the [ProjectName].csproj.DotSettings file.
Xml Node:
<s:String x:Key="/Default/CodeInspection/CSharpLanguageProject/LanguageLevel/#EntryValue">CSharp70</s:String>
This file can be safely deleted to get things back to default.
File for warnings 6.0 will be something like that:
<wpf:ResourceDictionary xml:space="preserve" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:s="clr-namespace:System;assembly=mscorlib" xmlns:ss="urn:shemas-jetbrains-com:settings-storage-xaml" xmlns:wpf="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
<s:String x:Key="/Default/CodeInspection/CSharpLanguageProject/LanguageLevel/#EntryValue">CSharp60</s:String>
</wpf:ResourceDictionary>
Related
I am attempting to move a solution from TFS 2012 to TFS 2018 SP2RC2 but I can't get the unit tests to run correctly. All projects have been re-targeted to 4.7.1 and are built as x86 platform. We have a testsettings file that supplies nothing but deployment items. I am using the new VSTest Platform Installer task (as directed by MS) and the VS Test Task. At the start of the test run I get the following message:
Test run will use DLL(s) built for framework .NETFramework,Version=v4.5 and platform X86. Following DLL(s) do not match framework/platform settings.
So all of the test are skipped as they target 4.7.1. Where is this 4.5 setting coming from? I cannot find it specified anywhere and can't figure out how to change it.
There is a /Framework: parameter that you can specify to VSTest.
In your case, you should specify /Framework:.NETFramework,Version=v4.7.1
See more at https://msdn.microsoft.com/en-us/library/jj155796.aspx?f=255&mspperror=-2147217396
To add this parameter in a Azure DepOps yaml pipeline, use the otherConsoleOptions argument
- task: VSTest#2
otherConsoleOptions: '/Framework:.NETFramework,Version=v4.7.1'
The fix I found for this in Visual Studio is way easier than I thought:
Exit all instances of VS
Open your project folder in Windows Explorer, find the .vs folder, delete it
Restart VS, the folder rebuilds itself, tests work again.
Apparently there are some settings that the NUnit plugin stashes in this folder and they are in binary so you can't edit them. This happened to me after I updated to NUnit3TestAdapter version 3.17.
I had trouble running a test project developed on another machine where no tests where able to be run using the MSTest test runner. In addition to message in your question I also got the messages:
Make sure that test discoverer & executors are registered and platform
& framework version settings are appropriate and try again.
Discover test finished: 0 found
In my case I resolved it by unloading and updating the .csproj file adding the following import directly under the root Project tag.
<Import Project="..\packages\MSTest.TestAdapter.1.3.2\build\net45\MSTest.TestAdapter.props" Condition="Exists('..\packages\MSTest.TestAdapter.1.3.2\build\net45\MSTest.TestAdapter.props')" />
Hope this answer will help save you some time.
I got this error using Visual Studio 2019 with NUnit 3.12.0:
Test run will use DLL(s) built for framework
.NETFramework,Version=v4.5 and platform X86. Following DLL(s) do not
match framework/platform settings.
Project.UnitTests.dll is built for Framework 4.5.2
and Platform AnyCPU.
Installed NUnit3TestAdapter 3.13.0 and then everything started working. Did not need to modify Framework version or CPU settings.
Had the exact same issue as Bill, working on legacy code in VS2019, nothing else had worked. I simply changed the Run Settings to use the Auto Detect.
In the menu go to Test -> Configure Run Settings -> Auto Detect runsettings File
For me skipping tests in local VS2022 run was related to testsettings file. I deleted .vs folder of my project then selected
Test ->Configure Run Settings -> Select Autodetect run settings file
After that I can debug unit tests
TLDR: If you use *.runsettings file for your test projects, try removing TargetFrameworkVersion node
I had similar problem but with .Net Core
Test run will use DLL(s) built for framework
.NETFramework,Version=v4.0 and platform X64. Following DLL(s) do not
match framework/platform settings. MyProject.Tests.dll is
built for Framework .NETCoreApp,Version=v3.1 and Platform AnyCPU.
Turns out there was another problem. For my other .NET Framework test projects I had defined *.runsettings file
And in this file I had
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<!-- Parameters used by tests at runtime -->
<TestRunParameters>
<Parameter name="ConnectionString" value="Data Source=localhost;Initial Catalog=MyDatabase;Integrated Security=True" />
</TestRunParameters>
<RunConfiguration>
<!-- Framework35 | [Framework40] | Framework45 | FrameworkCore10-->
<TargetFrameworkVersion>Framework40</TargetFrameworkVersion>
</RunConfiguration>
</RunSettings>
Supported values for TargerFrameworkVersions based on https://learn.microsoft.com/en-us/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file?view=vs-2019
are:
FrameworkCore10 for .NET Core sources, FrameworkUap10 for UWP-based
sources, Framework45 for .NET Framework 4.5 and higher, Framework40
for .NET Framework 4.0, and Framework35 for .NET Framework 3.5.
But for Core 3.1, FrameworkCore10 doesnt work!
So I removed node TargetFrameworkVersion completely
I had the same problem in VS 2019 on a legacy project.
Restarting Visual Studio did not help, nor did build as Release then rebuild as Debug, nor did deleting the .vs folder. I did those things and still was unable to run tests, getting a message like the OP's during test detection each time. I mention these here for completeness.
I deleted the LocalTestRun.testrunconfig file and the *.vsmdi file from Solution Explorer, cleaned and rebuilt the solution, and the unit tests worked again.
I was running into the same issue with the Visual Studio Test Task version 2 in an Azure Devops 2019 pipeline after a .csproj test project was upgraded from .NetFramework 4.6.1 to .NetCore 3.1.
The fix for us was to be more specific when specifying the test files. The default of **\*test*.dll was finding several other assemblies with "test" in their names that didn't exist before the upgrade. Using an explicit **\<MyTestAssemblyName>.dll fixed the issue.
I'm slowly migrating projects to VS2017 from VS2015. We have distributed team and until all is verified (there are issues with e.g. Reporting Services, SSIS, etc as there is not fully finished tooling - SSDT) I need the projects could work in VS2015 without changes.
C# projects in VS2017 use latest C# version by default in project settings (in my case it is C# 7.1) and ReSharper started to offer refactoring to these new features. However, I need to resist the temptation and wait until all is migrated (while I still need to be able to write and review code). I need to specify the version of C# to be 6.0. I can do it on per project basis but I would like to avoid this as I would have to go through each project, modify it and push it to source control and when the migration is done then I would have to switch it back.
Is there a way in R# to globally set the C# version in options (haven't found such a setting but maybe there's some hidden option?)
(VS2017 - 15.4.5, ReSharper 2017.2.2)
EDIT
For Typescript there is possibility to specify language level - either auto-detection or exact version. So for C# it could be similar - auto-detection from project settings or exact version. It would allow code review for specific language version without modification of the projects.
I'm adding here also the link to R# support page as I asked there too
Add the following string to solution settings file ({Solution name}.sln.DotSettings file in the solution's root folder)
<s:String x:Key="/Default/CodeInspection/CSharpLanguageProject/LanguageLevel/#EntryValue">CSharp60</s:String>
I'm trying to publish a newly created asp.net 4.6 web project to Azure web apps and receiving the following error:
remote: D:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.CSharp.targets(316,9): error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.Csc" task could not be loaded from the assembly D:\home\site\repository\packages\Microsoft.Net.Compilers.1.0.0\build..\tools\Microsoft.Build.Tasks.CodeAnalysis.dll. Could not load file or assembly 'Microsoft.Build.Utilities.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [D:\home\site\repository\WebApp\WebApp.csproj]
Everything builds fine via Visual Studio 2015 on my local machine. I thought Azure web apps were all set to support VS 2015 RTM upon release, but it would appear they do not have MSBuild 14.0 installed. Is there a work around or a roadmap for this problem?
Here was the fix for me.
Using Nuget Package Manager, remove these two packages if referenced:
Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Microsoft.Net.Compilers
After that, run a rebuild. This ensured that the build was not trying to use a specific build exe. Click here for the
Diff against previous revision
In my case I have to edit my .csproj file and find below lines and delete them
<Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props'))" />
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
Now everything is fine,
Azure Web Apps doesn't support ASP.NET 4.6 yet. It's on it's way though, so stay tuned.
In a Visual Studio 2012 C# console application, I downgrade ".NET Framework Target" from 4.5 to 4.0. Win 7 Pro with both Frameworks installed.
I then reference an assembly, which, through warnings complains the following:
The primary reference "System.Threading.Tasks.Dataflow, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the framework assembly "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0". To resolve this problem, either remove the reference "System.Threading.Tasks.Dataflow, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" or retarget your application to a framework version which contains "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
If I try to compile at this point, I error, becuase types and namespaces from referenced assembly aren't available, as if the assembly was not referenced at all.
The "Add Reference" dialog doesn't have any System.Runtime choice, but if I manually brose to
C:\Windows\Microsoft.NET\Framework\v4.0.30319\
and reference the System.Runtime assembly found there, warnings go away and I am able to compile.
Questions:
Is such forcing of the System.Runtime version a potential issue down the road (deployment).
If VS Project properties are seto to target Framework 4.0 (doesn't that relate to targeting the 4.0 SystemRuntime/CLR), why isn't the refferenced DLL picking that up and why manually adding the reference to my project fixes that issue?
Even though the library System.Runtime is inside the C:\Windows\Microsoft.NET\Framework\v4.0.30319\ directory, it is not part of the .NET 4.0 framework. .NET 4.5 is an in-place update of 4.0 and is installed in the same folder with the same version number.
Here is a screenshot that proofs that the library does not exist on a play .NET 4.0 installation:
You can also validate this by browsing to the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework directory where you find the original assemblies for all installed framework versions. You will find the System.Runtime.dll as part of the .NETCore\v4.5 and .NETPortable\v4.5 subdirectories.
The reason that you can add the library to your project is that the runtime did not change between 4.0 and 4.5, so Visual Studio doesn't know or even care that the library you added manually is installed by 4.5. In this case the targetting in Visual Studio is only a filter that avoids that you accidentally add a 4.5 assembly to a project that targets 4.0.
Additional information:
Rick Strahl has a very good blog post on the topic with a more detailed analysis:
http://www.west-wind.com/weblog/posts/2012/Mar/13/NET-45-is-an-inplace-replacement-for-NET-40
Is such forcing of the System.Runtime version a potential issue
Yes, this just won't work. It works on your machine because you have 4.5 installed. Your program will crash and burn on a client machine that only has 4.0. Never add a reference from the Framework directory. It is rather sad that they are still around, they get too many programmers in trouble, but backwards compat is sacred.
The build system can only tell you that you have a problem when you use the reference assemblies. The ones shown in the Add Reference dialog, they are stored in c:\program files\reference assemblies and are not the same as the runtime assemblies. You know that works, you did get the warning. Which, in a somewhat clumsy way, told you that you program won't work on a machine that has 4.0. Don't ignore that warning, you really do have to target 4.5 to use that assembly. Hard requirement you cannot avoid.
why isn't the refferenced DLL picking that up
Because it refuses to build a program that cannot run. Feature, not a bug.
I have a project using Reactive Extensions and ReactiveUI. I upgraded to the pre release version and I have the following line of code
OAPHCreationHelperMixin.ObservableToProperty(observable,
Function(x) x.Value
Visual studio tells me there is an error here on the method ObservableToPropertyin that the following assembly is missing
Error 9
C:\Users\phelan\workspace\WeinMeasEval\WeinMeasEval\Global\ObservableBinding.vb
Reference required to assembly
'System.Reactive.Interfaces,
Version=2.0.20823.0,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35'
containing the type 'System.Reactive.Concurrency.IScheduler'. Add one to your project.
Now I click the link which suggests it will add the reference and then nothing
happens. If I look in my project references I see that the assembly is indeed
in the assembly list and it is the correct version 2.0.20823.0 and if I look on
the path the DLL is indeed there.
Any ideas?
This is now fixed, check out ReactiveUI 4.0 Preview 5
It turns out that at this date reactive UI is not built yet for .NET 4.5 as the developer is having some build issues.
As a work around I build it myself by pulling the repository from Git and referring to the core library directly from within my .NET 4.5 project.
This seems to work at the moment. YMMV
Do you have Target Framework set to full .net or to Client Profile (in project settings)?