When I include JetBrains-ReSharper my project using NuGet Package Manager, and then I try to rebuild the project, it shows an error.
Error 14 The type 'System.Threading.LazyInitializer' exists in both 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\mscorlib.dll' and 'Project\packages\JetBrains.ReSharper.SDK.8.2.1158\bin\System.Threading.dll' Project\Filters\InitializeSimpleMembershipAttribute.cs
Can anybody can help me to solve the problem ?
Sadly, because ReSharper is a .net 3.5 application, and due to the way the SDK is set up, it includes references to the .net 3.5 compatible System.Threading.Tasks.dll back port Microsoft initially released with RX. The unfortunate part is that this file is referenced even if your plugin is a .net 4 project, and so you get conflicts with the real System.Threading.Tasks.
You can change your project to be .net 3.5, but then (again, due to the way the SDK is set up) you'll get other warnings about .net 4 assemblies that are referenced, but shouldn't be. Essentially, you just have to ignore those warnings. We're working on fixing all of this for 9.0.
However, as #derigel mentions in the comments - adding the ReSharper SDK to an MVC project is a little weird, and frankly, won't work. The ReSharper SDK is for building ReSharper plugin extensions. If you want to install ReSharper, download it from here: http://www.jetbrains.com/resharper/download/
Related
So I've made a back-end project in .NET 5.
I'm trying now to make a release pipeline in Azure Devops, where my code is also located.
Errors include:
Error : Version 5.0.100 of the .NET Core SDK requires at least version 16.8.0 of MSBuild. The current available version of MSBuild is 15.9.21.664. Change the .NET Core SDK specified in global.json to an older version that requires the MSBuild version currently available.
Error MSB4236: The SDK 'Microsoft.NET.Sdk.Web' specified could not be found.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(1179,5): Error MSB3644: The reference assemblies for framework ".NETFramework,Version=v5.0" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
In the above picture's the steps I take:
First I use the almost latest version of Nuget, 5.8.0
Then the next job is a "nuget restore".
The next step is to specifically specify it needs to use .NET 5 SDK (if this job isn't included, Azure Devops throws errors on this, stating that it can't find runtime=net50 etc...).
Here's the more in detail screen:
The next job is the "MSBuild" one, here in more detail:
This "MSBuild" job replaced my "Visual Studio Build" job, because here I could set it to version "16.0" but apparently this doesn't work? The regular "Visual Studio Build" details look just the same, even in my settings, but doesn't include the "MSBuild version" option. Using the regular "Visual Studio Build" option didn't work (see above errors as well).
The next jobs he doesn't even reach yet, so I'll presume for now they work correctly. The issue is indeed with the builds, using SDK, restore etc...
Does anyone who has more experience making azure pipelines/builds in .NET Framework 5.0 or higher have an idea what's wrong here and how I can fix this? Or even an idea where I should look?
I've been breaking my head over this the entire day and it's about to explode...
You should use a different type of tasks to restore/build etc .net core apps
https://learn.microsoft.com/en-us/azure/devops/pipelines/ecosystems/dotnet-core?view=azure-devops&tabs=dotnetfive
I have made a project in VS2019. I have the same project in .NET Core and .NET Framework. I use a COM reference in my project. I would like to migrate these projects to Pi4.
A simple Hello World project (.NET Core) is running successfully on the Pi4 machine. However, when I try to run my project (.NET core or .NET Framework) it does not run on the Pi4. It says COM is not supported.
I tried to build the project using MSBuild in my Windows environment after looking for solutions in Google. I also see a similar error here. The error is: error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild.
The .NET Framework project also gives a similar error.
error MSB4028: The "ResolveComReference" task's outputs could not be retrieved from the "ResolvedFiles" parameter. Object does not match target type.
Does anyone have similar issues?
https://github.com/microsoft/msbuild/issues/3986
According to the above link. The employee of Microsoft is saying they can not give solution in the near future.
Set the Projects to x86 for them to build the Interop, the Interop created still could not be used in x64 runtimes.
Add the COM Reference to the Core project, Build it and you will get an Interop.YourCom in the bin/x86/core/debug folder.
Remove the COM reference, and re-add the Interop, it will be put into the Assemblies Dependencies, and MSBuild will work.
My MSB4803 was from a WIXInstaller project, for ADOX, and Microsoft.Office.Interop.Access.Dao
I stumbled upon this question many times and I experienced the same several times in different projects. It doesn't matter if it is Visual Studio 2019 or 2022 and the version of the build, unless you are working with the old MSBuild in a legacy environment, the COM Reference doesn't work. It is always safe to build it in the command line to understand if anything in the VS environment works. I don't truly understand why Microsoft let you make those references in the Visual Studio environment when they will not work nearly anywhere else.
There are some workarounds that might or might not work but if your code is already pointing at a COM library there is no much to do. You can install the NuGet package which is going to pass the build stage and remove the COM reference.
Install-Package Microsoft.Office.Interop.Excel -Version 15.0.4795.1001
The NuGet package has some differences at the types level that you will need to fix (the COM reference allows you to get specific types instead of objects from the cells values)
In any case, you will need the COM installed in the server, there is no workaround that issue.
I wouldn't say I like this error message or the link it shows on how to fix it, to be polite.... ;-);
I figured it out and thought as there are a lot of answers that are not helpful to share mine. What I did is update your command to force the use of msbuild.
dotnet msbuild -v:normal "FullOrRelativePathTo\MyProject.csproj" -p:Configuration=RELEASE
If that fails, try:
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\msbuild.exe" "PathTo\Project.csproj" /p:Configuration=RELEASE
I know I'm late to the party, but here is a workaround working for me when I want to use Office Interop in .NET (Core):
Create an empty .net Console app (I'm using Rider and .NET 7)
Build it with the default MSBuild (17.0 in my case at the time of writing)
Add Interop references to the project file (I don't use Nuget, only generate these in a dummy .NET Framework project while adding COM references to Office libraries), eg.
<ItemGroup>
<COMReference Include="Excel">
<Guid>{00020813-0000-0000-C000-000000000046}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>9</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>False</Isolated>
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>
</ItemGroup>
Change the solution MSBuild version to 4.0
Try to build the solution, but the project will not even load properly due to an outdated MSBuild version
Revert the MSBuild version to the default one
Build the project - success! (this is the magic part, I can't explain it :P)
I have a Windows 2016 server that I am setting up as a build server. It will be setup to use MSBuild to build a .NET 4.6.1 Web API project I am using MSBuild version 15.0, and using TeamCity version 2018.1, however I do not believe TeamCity is really involved in the issue, as I get the issue by doing an MSBuild manually/directly against the code
Windows 2016 has .NET 4.7, so I installed the .NET 4.6.1 targeting pack and .NET 4.6.1 SDK. In the build step in TeamCity, I have a parameter to MSBuild of "/p:TargetFramework=net461" But in the build logs, and when I run MSBuild manually/directly against the code, I get the following error:
HttpExtensions.cs(44, 24): error CS8137: Cannot define a class or member that utilizes tuples because the compiler required type 'System.Runtime.CompilerServices.TupleElementNamesAttribute' cannot be found. Are you missing a reference?
HttpExtensions.cs(44, 24): error CS8179: Predefined type 'System.ValueTuple`2' is not defined or imported
When I am on my development machine with Visual Studio 2017 installed, the project builds without issue. My development machine is Windows 10, but the other major difference is that the Windows 2016 server does not have Visual Studio. My thoughts are this has something to do with Windows 2016 having the primary .NET version as 4.7, and installing Visual Studio would maybe fix the issue. But I really want to avoid installing Visual Studio on the Windows 2016 server
Any ideas/feedback ?
Either or both of the following errors implies that you are trying to use ValueTuples without having either a reference to System.ValueTuple or having a version of mscorlib.dll from NET 4.7 or higher.
error CS8137: Cannot define a class or member that utilizes tuples because the compiler required type 'System.Runtime.CompilerServices.TupleElementNamesAttribute' cannot be found. Are you missing a reference?
error CS8179: Predefined type 'System.ValueTuple`2' is not defined or imported
The simple solution is to add a nuget reference to the most up to date version of System.ValueTuple and your project will then build in NET 4.6.1. See here for more details.
The reason why this works locally for you, but doesn't on your build machine is slightly more complex (and entirely theoretical, since I don't have machines of those specs to test it out).
See this question for an explanation of how MSBuild works when it doesn't have the correct targeting pack available.
Your build machine was building your project as requested. MSBuild 15.0 saw that it needed to build a project to target NET 4.6.1, found the correct targeting pack / SDK and pulled in a reference to the NET 4.6.1 mscorlib.dll, and correctly found that with this dll it had no reference to ValueTuples and couldn't build your project.
My guess is (and I'm happy to be wrong here) that you don't have the targeting pack / SDK for Net 4.6.1 installed on you local machine and as such msbuild defaults to the NET framework associated with 15.0 which is (I think) NET 4.7. This means that the mscorlib.dll that gets used is the NET 4.7 one which does contain an in-built ValueTuple type.
Ordinarily adding the nuget reference would cause a conflict for your local build (you have 2 structs from different sources with the same name (ValueTuple)), but Microsoft appear to have done something clever so that the version from the Nuget package is ignored if ValueTuple is contained in the mscorlib.dll. See comments here.
This all feels very nasty, and I personally would prefer if MSBuild threw a hard error if it couldn't find the correct targeting pack, but that's not how it works currently.
Thanks to #Ross Gurbutt for pointing in me the right direction. While it's easy to find through googling about the issue related to referencing System.ValueTuple when it's .NET 4.6.1 versus 4.7, what was confusing was that it was compiling successfully on my local without a reference. Nonetheless, I added a reference to the nuget package, and the Windows 2016 server with MSBuild v15.0 was able to build the Web API project successfully
I was going through the latest features introduced in C# 6.0 and just followed an example of auto property initializer,
class NewSample
{
public Guid Id { get; } = Guid.NewGuid();
}
but my IDE did not recognize the syntax.
I am wondering how I could enable C# 6.0 in Visual Studio 2013. The Target framework I am using is 4.5.1.
Under VS2013 you can install the new compilers into the project as a nuget package. That way you don't need VS2015 or an updated build server.
https://www.nuget.org/packages/Microsoft.Net.Compilers/
Install-Package Microsoft.Net.Compilers
The package allows you to use/build C# 6.0 code/syntax. Because VS2013 doesn't natively recognize the new C# 6.0 syntax, it will show errors in the code editor window although it will build fine.
Using Resharper, you'll get squiggly lines on C# 6 features, but the bulb gives you the option to 'Enable C# 6.0 support for this project' (setting saved to .DotSettings).
As mentioned by #stimpy77: for support in MVC Razor views you'll need an extra package (for those that don't read the comments)
Install-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
If you want full C# 6.0 support, you'll need to install VS2015.
Information for obsoleted prerelease software:
According to this it's just a install and go for Visual Studio 2013:
In fact, installing the C# 6.0 compiler from this release involves little more than installing a Visual Studio 2013 extension, which in turn updates the MSBuild target files.
So just get the files from https://github.com/dotnet/roslyn and you are ready to go.
You do have to know it is an outdated version of the specs implemented there, since they no longer update the package for Visual Studio 2013:
You can also try April's End User Preview, which installs on top of Visual Studio 2013.
(note: this VS 2013 preview is quite out of date, and is no longer updated)
So if you do want to use the latest version, you have to download the Visual Studio 2015.
A lot of the answers here were written prior to Roslyn (the open-source .NET C# and VB compilers) moving to .NET 4.6. So they won't help you if your project targets, say, 4.5.2 as mine did (inherited and can't be changed).
But you can grab a previous version of Roslyn from https://www.nuget.org/packages/Microsoft.Net.Compilers and install that instead of the latest version. I used 1.3.2. (I tried 2.0.1 - which appears to be the last version that runs on .NET 4.5 - but I couldn't get it to compile*.) Run this from the Package Manager console in VS 2013:
PM> Install-Package Microsoft.Net.Compilers -Version 1.3.2
Then restart Visual Studio. I had a couple of problems initially; you need to set the C# version back to default (C#6.0 doesn't appear in the version list but seems to have been made the default), then clean, save, restart VS and recompile.
Interestingly, I didn't have any IntelliSense errors due to the C#6.0 features used in the code (which were the reason for wanting C#6.0 in the first place).
* version 2.0.1 threw error The "Microsoft.CodeAnalysis.BuildTasks.Csc task could not be loaded from the assembly 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.
UPDATE One thing I've noticed since posting this answer is that if you change any code during debug ("Edit and Continue"), you'll like find that your C#6.0 code will suddenly show as errors in what seems to revert to a pre-C#6.0 environment. This requires a restart of your debug session. VERY annoying especially for web applications.
It worth mentioning that the build time will be increased for VS 2015 users after:
Install-Package Microsoft.Net.Compilers
Those who are using VS 2015 and have to keep this package in their projects can fix increased build time.
Edit file packages\Microsoft.Net.Compilers.1.2.2\build\Microsoft.Net.Compilers.props and clean it up. The file should look like:
<Project DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>
Doing so forces a project to be built as it was before adding Microsoft.Net.Compilers package
It is possible to use full C# 6.0 features in Visual Studio 2013 if you have Resharper.
You have to enable Resharper Build and voilá!
In Resharper Options -> Build - enable Resharper Build and in "Use MSBuild.exe version" choose "Latest Installed"
This way Resharper is going to build your C# 6.0 Projects and will also not underline C# 6.0 code as invalid.
I am also using this although I have Visual Studio 2015 because:
Unit Tests in Resharper don't work for me with Visual Studio 2015 for some reason
VS 2015 uses a lot more memory than VS 2013.
I am putting this here, as I was looking for a solution for this problem for some time now and maybe it will help someone else.
It seems there's some misunderstanding. So, instead of trying to patch VS2013 here's and answer from a Microsoft guy: https://social.msdn.microsoft.com/Forums/vstudio/en-US/49ba9a67-d26a-4b21-80ef-caeb081b878e/will-c-60-ever-be-supported-by-vs-2013?forum=roslyn
So, please, read it and install VS2015.
I have just installed the nuget package of Resharper and build the solution then I am getting these error on each Task type methods. It seems that it is because of two Threading.Task.dll files.
Error :
Error 87 The type 'System.Threading.Tasks.Task' exists in both 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETCore\v4.5\System.Threading.Tasks.dll' and 'C:\Users\emp70\Documents\Visual Studio 2012\Projects\FSOP\packages\JetBrains.ReSharper.SDK.8.2.1158\build\..\Bin\System.Threading.dll' C:\Users\emp70\Documents\Visual Studio 2012\Projects\FSOP\FSOP\ViewModel\DashBoardVM.cs 1604 22 FSOP
How to solve this conflict ?
Before installing Resharper everything was just working fine.
Unfortunately, this is a known issue with the SDK. ReSharper is a .net 3.5 application, and we're using a port of System.Threading.Tasks to get Task support. Sadly, this gives conflicts with a .net 4 project. This is something we're actively addressing in the next version - there are major changes to the SDK and the architecture in the works.
Sadly, there isn't an entirely satisfactory workaround. You can make your plugin a .net 3.5 plugin, but then you'll get a lot of warnings about .net 4 assemblies that are referenced but won't get used - you can safely ignore these, as they're essentially end user features that you won't need to reference in your plugin, but they're annoying (this is what I do). Alternatively, you can not use Task. Again, not ideal, but I've written quite a few plugins, and haven't had to use Task yet. YMMV.
Simply deleting/renaming the copy of System.Threading.dll within the packages folder should resolve the ambiguity, you should contact jetbrains to get it properly fixed.