I have the following version of Visual Studio:
Microsoft Visual Studio Community 2017 Version 15.1 (26403.7) Release
VisualStudio.15.Release/15.1.0+26403.7
I created a new project and added a .editorconfig file at my solution base folder.
Its content is the following:
root = true
[*.cs]
indent_style = space:warning
indent_size = 12:warning
# C# and Visual Basic code style settings:
[{*.cs,*.vb}]
dotnet_style_qualification_for_field = false:warning
The file location should be right:
.editorconfig <-- Here it is
ApplicationInsights.config
App_Data
App_Start
bin
Content
Controllers
favicon.ico
fonts
Global.asax
Global.asax.cs
Models
obj
packages.config
Properties
Scripts
Startup.cs
Views
Web.config
Web.config.backup.1
Web.Debug.config
Web.Release.config
WebApplication8.csproj
WebApplication8.csproj.user
But whenever I edit a .cs file, nothing special happen (despite indentation not following the rule), I expect a warning (after a build, for instance) to show up, but no.
Is there something wrong with my configuration, or is there something which could hinder the configuration from being applied?
I had this same problem. The solution was adding the .editorconfig file to the solution in my case. You can choose to either add it to the solution or the project, depending on whether you want it applied everywhere or just the individual project.
Solution Explorer → right-click your solution or project → Add → Existing Item... (if you have the .editorconfig file in position at the root of the solution or project) or New Item... (then search for editorconfig in the Add New Item wizard and choose the appropriate type for your work).
I solved a similar issue by placing the .editorconfig file at the root folder of the project, i.e., the same folder as your .sln file.
Try to put the .editorconfig file into the same folder as your source file. If it helps, try to move it up (into one of the parent directories) until you get it high enough to affect all the files you need.
If you have any EditorConfig extensions installed, try to uninstall them. There were some related bugs reported.
I had a similar problem and this is how I solved it:
My solution folder had a parent folder named between square brackets [], like [ParentFolderName], so I removed the square brackets and everything worked as expected.
For a reason or another, the editorconfig file does not do anything when the solution folder has a parent folder named between square brackets. The IDE (in my case Visual Studio 2017) uses its settings.
Related
When I build my application I get the following error
Error CS0579 Duplicate 'global::System.Runtime.Versioning.TargetFrameworkAttribute' attribute MyUIApp
D:\MyUIApp\obj\Debug\netcoreapp3.1\.NETCoreApp,Version=v3.1.AssemblyAttributes.cs 4 Active
The following code is autogenerated in the obj/Debug/netcoreapp3.1 folder
//
using System;
using System.Reflection;
[assembly: global::System.Runtime.Versioning.TargetFrameworkAttribute(".NETCoreApp,Version=v3.1", FrameworkDisplayName = "")]
I have a project file starting with
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<OutputType>Library</OutputType>
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<RestorePackages>true</RestorePackages>
<UseWindowsForms>true</UseWindowsForms>
</PropertyGroup>
<PropertyGroup>
I can work around the issue by commenting out the contents of the file, but not by deleting the file.
I was also getting this error in VS Code and the following fixed it.
I have a project/solution with three projects within in.
netstandard2.1
netstandard2.1
netcoreapp3.1
I added the following line to each of the *.csproj files within the <PropertyGroup> section:
<GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute>
Full example
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.1</TargetFramework>
<GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>
</Project>
After doing the above you might need to clean /bin and /obj folders for each project.
This article pointed me in the right direction though nothing online that I found mentioned the attribute above. I just guessed and it worked!
Add the following two lines to the <PropertyGroup>. This fixed it for me.
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute>
</PropertyGroup>
The problem was about my folder structure : the test project was in the main project folder. Passing each side by side in the same repo solved the problem
MyProject
src/MyProject.csproj
tests/MyTestProject.csproj
Taken from Github issue : https://github.com/dotnet/core/issues/4837
So i did encounter the same on a .NET 4.7 based solution, spent hours, only to find out a colleague of mine did include the obj and bin folders in the project!
excluding them fixed the issue and that error went away.
hope this save someone a couple of hours.
I fixed this by deleting the obj and bin folders in each project directory. I then cleaned the solution and rebuilt. The rebuild succeeded.
You just need to exclude the obj folder from the project/solution.
I was facing the same issue in my asp.net core 3.1 application right after I add the xUnit project to the solution. Ultimately, the main issue was because of that I selected the check box Place solution and project in the same directory as shown in the preceding image.
This should work in normal cases, and you will just consider this root directory as the Git repository (the .sln file and the .csproj will be in the same folder). But you will not be able to add a new project to this directory as you will get the error "Error CS0579 Duplicate 'global::System.Runtime.Versioning.TargetFrameworkAttribute'". So, to fix this error, we just have to follow the preceding steps.
Create a folder with the same name in the .sln file
Move all the project-related files to that directory
Open your .sln file with any code editor
Edit the Project references.
Make sure that your .sln file is in the root directory
This is how your project file references may look like now.
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WebApplication2", "WebApplication2\WebApplication2.csproj", "{027937D8-D0E6-45A4-8846-C2E28DA102E6}"
EndProject
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WebApplication2.Tests", "WebApplication2.Tests\WebApplication2.Tests.csproj", "{AD4C6C31-F617-4E76-985A-32B0E3104004}"
EndProject
That's it. Just reload your solution and happy coding!.
Try to delete obj folder from Project, delete it from SolutionExplorer instead of WindowExplorer.
I encountered that issue, what I did is I deleted the .NETCoreApp,Version=v3.1.AssemblyAttributes.cs and then I ran VSCode as an administrator.
I had this when my folder structure got messed up. I'm using Visual Studio 2019 and switched branches that has different folder structure. Some folders got added up in the file explorer and didn't get deleted even if I switched branches. All I did was to delete those folders that weren't part of my current branch and it worked.
I am having the same problem. As far as I can tell, the flag should prevent the auto-generation of assembly info. However, I can see this file in my obj directory:
.NETStandard,Version=v2.1.AssemblyAttributes.cs
It only contains the target version attribute. Maybe there is some other way of suppressing this attribute?
It seems like this might be a regression in .NET core 3.1.300. I was building with .NET core 3.1.200 and I didn't see this issue until I upgraded.
I experienced this on a build pipeline in Azure Devops. I was using a local agent to run the pipeline on (my own machine). It appears that there was code in the working directory that was causing this conflict, and by default, the agent doesn't clean the working directory before starting the pipeline process.
The fix was to delete the contents of the working directory on the agent. I did this by selecting the option to clean the working directory:
I had this kind of Errors in my Blazor Server project when I tried to add .NET Standard Class Library project in Visual Studio 2019.
Errors:
To fix this i tried following ways.
.csproj file Before
.csproj file After
In my case the culprit was my test project so I had to go to my test folder > obj > Debug/net6.0 > .NETCoreApp,Version=v6.0.AssemblyAttributes.cs
and then commented this line
[assembly:global::System.Runtime.Versioning.TargetFrameworkAttribute(".NETCoreApp,Version=v6.0", FrameworkDisplayName = "")]
This error can also happen if you accidentally copied an project file into another projects folder.
in my case (.NET 6.0);
I just exclude the Properties folder from the project/solution.
From the many different kind of answers, it's clear that there could be different reasons for the same issue. In my case the solution definition file was the cause. I decided to delete and create a clean solution file.
Delete the .sln file
Create a blank .sln file, in the root of your project/solution:
dotnet new sln
For every C# project file in your solution, add it with the following command, for example:
dotnet add MyApplication.csproj
and for example:
dotnet add CustomPackages/MyLibrary.csproj
Then to make sure all previous build artefacts are cleaned up
dotnet clean
Encountered this issue when working with AWS Lambda. Turns out I was switching branches, and some auto-generated folders did not get cleared after switching to new branch, and dotnet was picking them up for some reason. The easiest solution is to delete all local project folders, and check out clean version of the code again.
I commented out the offending attribute
// obj/Debug/netcoreapp3.1/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs
using System;
using System.Reflection;
//[assembly: global::System.Runtime.Versioning.TargetFrameworkAttribute(".NETCoreApp,Version=v3.1", FrameworkDisplayName = "")]
DELETE [assembly: global::System.Runtime.Versioning.TargetFrameworkAttribute(".NETCoreApp,Version=v6.0", FrameworkDisplayName = "")]
I was able to solve this issue by getting a new clone of the project.
I want to streamling code analysis and the respetive rules accross multiple projects and teams.
We used to do that by having a NuGet package that imported analyzers to projects (Microsoft.CodeAnalysis.FxCopAnalyzers and StyleCop.Analyzers) and defined a ruleset to define how each rule was handled by VS (error, warning, etc.).
I have been trying to setup this using a common .editorconfig file instead of the ruleset. The problem is that settings like the following just seem to be ignored when the .editorconfig file is imported from a shared folder.
dotnet_diagnostic.CA1062.severity = error
For the purpose of testing this, I have a very simple scenario that illustrates the problem.
The .editorconfig file is as follows:
[*.cs]
dotnet_diagnostic.CA1062.severity = error
#dotnet_code_quality.null_check_validation_methods = NotNull
Now this file is imported in a csproj like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<Import Project="..\..\_Shared\Build.props" />
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis.FxCopAnalyzers" Version="2.9.4">
<PrivateAssets>All</PrivateAssets>
</PackageReference>
</ItemGroup>
</Project>
Build.props is like this:
<Project>
<PropertyGroup>
<SkipDefaultEditorConfigAsAdditionalFile>true</SkipDefaultEditorConfigAsAdditionalFile>
</PropertyGroup>
<ItemGroup Condition="Exists('$(MSBuildThisFileDirectory)\.editorconfig')" >
<AdditionalFiles Include="$(MSBuildThisFileDirectory)\.editorconfig" />
</ItemGroup>
</Project>
The following code is supposed to trigger an error on CA1062:
public int Calculate(InputData input)
{
SmartGuard.NotNull(nameof(input), input);
if (this.Multiply)
{
return input.Value * 2;
}
else
{
return input.Value + 2;
}
}
But the result is a warning:
Now, if I change .editorconfig and uncomment the second line:
[*.cs]
dotnet_diagnostic.CA1062.severity = error
dotnet_code_quality.null_check_validation_methods = NotNull
The error goes way which means that null_check_validation_methods is being considered.
Why is that dotnet_diagnostic.CA1062.severity = error is being ignored?
This and other issues with the .editorconfig mechanics were reported in the following issues:
https://github.com/dotnet/roslyn/issues/38782
https://github.com/dotnet/roslyn/issues/43080
These have been solved and the original question is answered by implementing the recommendations referenced in those issues.
The problem you have comes from the fact, that the ".editorconfig" file mechanics (which is not defined by Visual Studio or Microsoft - it's pre-existing standard) is based on where the files are located in the folder structure. It has nothing to do with the mechanics of the Visual Studio projects.
See here on Microsoft's mention of this:
When you add an .editorconfig file to a folder in your file hierarchy, its settings apply to all applicable files at that level and below. You can also override EditorConfig settings for a particular project, codebase, or part of a codebase, such that it uses different conventions than other parts of the codebase. This can be useful when you incorporate code from somewhere else, and don’t want to change its conventions.
To override some or all of the EditorConfig settings, add an .editorconfig file at the level of the file hierarchy you want those overridden settings to apply. The new EditorConfig file settings apply to files at the same level and any subdirectories.
[ hierarchy image here ]
If you want to override some but not all of the settings, specify just those settings in the .editorconfig file. Only those properties that you explicitly list in the lower-level file are overridden. Other settings from higher-level .editorconfig files continue to apply. If you want to ensure that no settings from any higher-level .editorconfig files are applied to this part of the codebase, add the root=true property to the lower-level .editorconfig file:
# top-most EditorConfig file
root = true
EditorConfig files are read top to bottom. If there are multiple properties with the same name, the most recently found property with that name takes precedence.
Or here for the EditorConfig project.
Or here for the EditorConfig specification:
File Processing
When a filename is given to EditorConfig a search is performed in the directory of the given file and all parent directories for an EditorConfig file (named “.editorconfig” by default). Non-existing directories are treated as if they exist and are empty. All found EditorConfig files are searched for sections with section names matching the given filename. The search shall stop if an EditorConfig file is found with the root key set to true in the preamble or when reaching the root filesystem directory.
Files are read top to bottom and the most recent rules found take precedence. If multiple EditorConfig files have matching sections, the rules from the closer EditorConfig file are read last, so pairs in closer files take precedence.
I use Visual Studio version 16.11.2 and my experience is that the problem you describe appears, as a bug, when editing a project file in Visual Studio AFTER you have added a link to it to a it as a solution item. After such an action StyleCop does not any longer listen to the .editorconfig-file of the project.
To re-trigger StyleCop errors as build errors I then have to:
Remove the link to the .editorconfig for the project.
Add a copy of .editorconfig to the project.
Remove the copy of the .editorconfig to the project.
Re-add the link to the .editorconfig.
Quite akward yes, but the above DOES trigger the errors to appear as build errors again.
Moreover, in the version of Visual Studio above, I need to have the line below in the .csproj-file:
<PropertyGroup>
<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
</PropertyGroup>
For previous versions of Visual Studio I had to have the lines below instead:
<PropertyGroup>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<WarningsAsErrors></WarningsAsErrors>
</PropertyGroup>
I was trying to #include a cpp file with some functions so I can use that cpp file later with other projects. It gave me an 'already defined in .obj' error and since then that .cpp file was like binded with my project. (I understood that's not the way, the answer here helped me with the already defined)
If I exclude the .cpp file from the project, remove it from the directory and remove the #include line it still looks for it:
c1xx : fatal error C1083: Cannot open source file: 'std.cpp': No such file or directory
Diagnostic:
Outputs for D:\MY DOCUMENTS\C#\PROJECT\D3DTESTC++\COWS AND BULLS\CBMAIN.CPP|D:\MY DOCUMENTS\C#\PROJECT\D3DTESTC++\COWS AND BULLS\STD.CPP: (TaskId:15)
It shouldn't be looking for the std.cpp at all, I removed it! So is there a way I can reset the project and recompile so that the program doesn't look for it? I already tried Rebuild and Clear -> Build Project
When I ran across a similar problem with VS Express, I wound up having to open up the the .vcxproj file (which is just XML), and remove the offending
< ClInclude Include="FILEPATHANDNAME" > tags.
Many of the solutions here will not work
Fullproof method:
Open the vxproj file that is giving you trouble in a text editor.
remove all references to the file it cannot find.
OK, I have no idea how I did it but I'm still going to try to write what I did.
Save all and Close solution
Open the .vcxproj file (not .sln)
Build -> Clean [Project Name]
Save all and Close
Open the .sln file again.
Build -> Project Only -> Clean Only [Project Name]
Build -> Project Only -> Build Only [Project Name]
That's exactly what I did and worked for me. I think the main thing to do is clean, save, close, open, build, but I'm not sure.
In Solution Explorer you can select/deselect option "Show All Files".
Try both options and make sure excluded file is not included in project for both of them.
That's what I had:
I used "Show All Files" option (so you can see all the files in project directories). I excluded one of my .cpp files from project. However, it behaved as this file is in project.
That's how I managed to fix it:
I switched "Show All Files" off and saw this file still belongs to project! So I excluded this file once again.
As I see, that's a known issue.
This worked for me, hope it will be useful for someone else.
Try to verbose builder output to see exact steps of what's going on. I suppose, you use Visual Studio, right?
Go to menu "Tools -> Options"
In options dialog, select "Projects and Solutions -> Build and Run"
Change current mode of "MSBuild project build output verbosity" from "Minimal" to something like "Diagnostics" or "Detailed".
Rebuild your project and investigate Output windows
Builder dump should shed more light on your current settings (I suspect you have more references to that file than you expect)
This happened to me because I renamed folder from inside the IDE. None of the above solutions worked. The only way to fix this is by opening vcproj in notepad and you should see the offending files in the <ItemGroup>. Just delete those lines.
Or sometimes, like in my case, the issue is simply in the naming of the folders in the location. I had a very long path with folders that I like to name with special characters so they show up at the top and it's easy to access them.
As soon as I put my solution in a folder just in D: drive, the issue was gone.
When I renamed a file, I found I had to go to SolutionExplorer, Source File, select the file, first exclude from Project, then re-add it to project, and rebuild the solution it lives in. It was still showing up as the old file name under Source Files for me.
I had the same problem, but I had another .sln worked fine. After tooling around with the Project->Properties-> to make them look identical, nothing worked. I opened both .vcxproj files and copied the contents of the working version into my non-working version. (I noticed that the two files had different lengths. The non-working version was longer by about 20 lines.) I just changed the RootNameSpace to the non-working version's name. I saved the non-working file and presto! It worked.
I removed those sources from Project and re-added them. Somehow, references were messed up after a hurry project refactoring.
For people having problem related to "error C1083: Cannot open source file":
Error is caused by settings in *.vcxproj file. Probably you deleted/moved source file by file explorer, not by Visual Studio's "Solution Explorer". Thus, your *.vcxproj file is corrupted. Fix is to manually correct settings in *.vcxproj file.
How Visual Studio settings files work
Visual Studio saves solution's info into file. This file is usually in project's solution directory, has extension .sln and base name is same as name of solution, f.ex.:
NameOfSolution.sln
Similarly, project's info is saved into one file (each project has its own file). Base name of this file is name of project, extension is .vcxproj, and usually is located in subdirectory named as your project, f.ex.:
NameOf1stProject/NameOf1stProject.vcxproj
NameOf2ndProject/NameOf2ndProject.vcxproj
Both *.sln and *.vcxproj files are textual files. You can open them by using Notepad.
How to fix problem
Find *.vcxproj file responsible for your project.
If you don't know where it is, open in Notepad the *.sln file of your solution. Search for name of your solution. You will find line like:
Project("{9AA9CEB8-8B4A-11D0-8D22-00B0C01AA943}") = "NameOf1stProject", "NameOf1stProject\NameOf1stProject.vcxproj", "{A8735D0A-25ED-4285-AB8F-AF578D8DB960}"
Value under "NameOf1stProject\NameOf1stProject.vcxproj" is location of *.vcxproj file of your project.
Open found *.vcxproj file by text editor (f.ex. Notepad).
Search for line on which is filename you are struggling with.
Example: if you are looking for "RemovedFile.cpp", then you should find line:
<ClCompile Include="RemovedFile.cpp" />
Delete that line.
If you have opened Visual Studio, it asks you if it should refresh solution - select yes. If it is not opened - just start using it.
In case of any problems, try to rebuild solution (top banner -> Build -> Rebuild Solution)
In my cases, it worked. 30 mins of trying to fix, <1 minute of fixing.
This helped in my case. To sum it up, my path to the project was too long, so I moved my project to something shorter i.e. D:\my_project and everything worked in a blink of an eye.
I had this same problem, but for me the issues was that I was using Bash on Windows (WSL) to clone the repository and then using VS to compile.
Once I deleted my clone and used Windows command line (cmd.exe) to clone the repo then the error 1083 went away.
This is caused by not removing/deleting the file properly. Go to Solution Explorer, select your solution, at the left corner, activate the icon: show all files.
(if you already removed the problem file, restore it from recycle bin)
Select the problem file, do remove and delete from within Solution Explorer and you should not have this problem. And remember to do it the proper way from now on.
This is on MS 2010
If you have that file in your project directory but you still got the error, on your IDE go to Solution explorer--> Remove that file-->then open the project directory on your file explorer-->Select that file and drop it on a specific location in IDE solution explorer. I fixed it this way. I use the Windows platform.
I got this error when I got a code from my peer and I tried directly running it on my system. Ideally to avoid such errors, I should have just copied the source and header files and should have created the VS solution of my own.
To resolve the errors I removed the files from the Solution Explorer and added them again. Following image shows the Solution Explorer window.
The remove option comes after right clicking on the file names.
I have combined several projects into one solution. I created empty solution and added these projects and here is a blue print of how it looks like:
Root:
Project1 - directory
Project2 - directory
Debug - directory
Main.sln - file
Now I want to direct the executable and dll from both projects to \debug folder shown up of the solution file. I go into project properites >> Configuration Properities >> General >> 'Output Directory' and change the output directory to $(SolutionDir)$(Configuration)\ which is default for a new project.
The problem is that it has no effect on where the output file is created, it is still created in the old destination. The old path for `Output Directory' was .\Debug\ not that it matters.
Could this be because the SolutionDir & Configuration may not be defined? Where can I see their definition or values? I also want to create a new configuration which would be 'Release with Debug' how can I create that using environment variable? Thanks!
My project is MFC/Visual C++.
Add-on:
Where are these identifiers like SolutionDir defined in the scrip? I look up for in .vcxproj file but there is mention of it. I create a new dummy VS2010 project just to look at it's .vcxproj file but these project settings identified are not defined in any place that I can see!
This is most likely caused by specific settings overriding global settings, namely Linker's "output" setting. This happens often as a result of conversion from earlier Visual Studio.
What you need is to go through every setting, paying attention to those whose values are written in bold, and reset to default (select it from dropdown) every setting with 'debug' or 'release', and others as necessary.
There could also be specific settings on files. I usually resolve this by opening project in notepad and removing any excessive settings. Just be careful. Using multiline replace in Notepad++ or any other capable editor helps.
I think I had a similar problem.
What I ended up doing was editing the vcxproj file directly. Find this section and edit it like this for each of your configurations:
<PropertyGroup>
<OutDir Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">$(SolutionDir)$(Configuration)\</OutDir>
<OutDir Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(SolutionDir)$(Configuration)\</OutDir>
</PropertyGroup>
I had a similar problem with the Intermediate Directory setting in one of my VS2010 projects. No matter what I set it to, it would always use the default value of $(SolutionDir)$Configuration. Oddly, other projects in the same solution with the same settings worked just fine.
After playing around, I stumbled upon a solution.
Click on the setting in the propery page dialog.
Click on the down arrow button in the right-hand side of the edit box.
Select "inherit from parent or project defaults".
Click "Apply".
Click on the setting and change it to your desired value.
I don't know why this works, but it does. It seems like the macros were not being properly evaluated for whatever reason. Then, after you apply the inherited values, it seems to reset itself and start evaluating the macros properly.
I would like Visual Studio to automatically put my .h file in a folder /ProjectPath/include and my src file in /ProjectPath/src. That way, if I use the "Create class wizard" for instance, it would put the good path by default without me having to change the folder. Anyone know what setting I should change to get this behaviour when I add file ?
Thanks,
Jean-Philippe
You can right click on a folder in solution explorer and go to properties, you need to set the Filter property.
For example the Source Files folder by default has a filter like this in a C++ project: cpp;c;cc;cxx;def;odl;idl;hpj;bat;asm;asmx