Is there any FxCop or StyleCop that warns when there is an using statement that is no longer referenced by any object in the file?
You can enable the rule IDE0005 C# Using directive is unnecessary. in the category Style.
In addition to Udo's answer and this answer, I also needed to uncheck Suppress results from generated code (managed only) which can be found under Properties > Code Analyses.
So all in all:
Set the Warning Level to 4 for code analyzers to fire.
Set rules CS8019 and IDE0005 to warning in your projects' Code Analysis rules (Properties > Code Analysis).
Make sure to uncheck Suppress results from generated code (managed only) which can be found under Properties > Code Analyses.
Related
What has become of the CMake CLEAN_DIRECT_OUTPUT property used in the set_target_properties command? The CMake Properties on Targets page doesn't mention it but it appears in some CMakeLists.txt files I've seen.
Googling for CLEAN_DIRECT_OUTPUT doesn't seem to give much insight into this question. At best, links like linux.die.net document what this property is for:
When a library is built CMake by default generates code to remove any existing library using all possible names. This is needed to support libraries that switch between STATIC and SHARED by a user option. However when using OUTPUT_NAME to build a static and shared library of the same name using different logical target names the two targets will remove each other's files. This can be prevented by setting the CLEAN_DIRECT_OUTPUT property to 1.
And that seems like an important function!
Searching for this property on cmake.org however, shows "no results found".
Fortunately, the cmake source code and its revision history can be found online. Searching the git log history, reveals a commit, dated May 1 2009 by Brad King, that sheds some light into this question.
This commit's log message is as follows:
ENH: Always imply CLEAN_DIRECT_OUTPUT target prop
This property was left from before CMake always linked using full path
library names for targets it builds. In order to safely link with
"-lfoo" we needed to avoid having both shared and static libraries in
the build tree for targets that switch on BUILD_SHARED_LIBS. This meant
cleaning both shared and static names before creating the library, which
led to the creation of CLEAN_DIRECT_OUTPUT to disable the behavior.
Now that we always link with a full path we do not need to clean old
library names left from an alternate setting of BUILD_SHARED_LIBS. This
change removes the CLEAN_DIRECT_OUTPUT property and instead uses its
behavior always. It removes some complexity from cmTarget internally.
Accordingly, the commit's source code changes show that functionality, documentation, and uses of CLEAN_DIRECT_OUTPUT was removed.
Bottom line appears to be: the CLEAN_DIRECT_OUTPUT property has been removed and instead its behavior is always used.
In VS2017, I had several different build configurations that built an application in different ways. One configuration would produce the default application. Another build configuration would produce the application with more features, etc.
This was done in the source code with #if FEATURE blocks. FEATURE was defined in the Conditional compilation symbols for a project's build configuration.
Now, I ported the code to Visual Studio 2022. It appears that the Conditional compilation symbols are now part of the project and not part of the build configuration. So I have to define FEATURE for the project and not the build configuration.
I've used #if FEATURE to put in attributes to classes and methods, so I can't replace this with a simple if statement in the source code.
I don't want to change the project settings every time I need to build the different applications.
What is the workaround for being able to build a project with different compilation symbols easily?
Realise this is a year old now, but I've been looking at conditional compilation symbols this morning.
First, have a look at this: https://learn.microsoft.com/en-gb/dotnet/csharp/language-reference/compiler-options/language
The <DefineConstants> section deals with conditional compilation.
Edit the .csproj file directly, and in any applicable property group you can define constants that you can reference in code. e.g.
<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
<DefineConstants>MYDEBUGCONSTANT</DefineConstants>
</PropertyGroup>
Then in code you can use:
#if MYDEBUGCONSTANT
// Some debug code
#endif
I had some issues with the conditions on the property groups, VS2022 got a little confused when two of the property groups applied at the same time. Once I sorted that everything worked as expected.
Hope that helps?
I'm the author of some library which gets built using CMake.
If a user specifies a build type they run cmake - I can oblige that, no problem.
But what is the best practice when a user doesn't specify a build type?
Should I just ignore it?
Should I choose a build type as a fallback/default myself? If so, which?
I've read this Kitware blog entry which suggests a certain approach to the matter and places it in a library dependency. The approach is encapsulated into this module. Should I use that?
So far I've been forcing some specific build type and it's been suggested to me perhaps I shouldn't be doing that.
I think there are two good options:
Warn the user if CMAKE_BUILD_TYPE is unset and the active generator is single-config.
Do nothing. The warning is only helpful to novice users, anyway. It is possible (however unlikely) that an advanced user intended to do this. In this case, the warning is annoying.
To implement (1) correctly, the following code snippet (placed early, ideally after project()) will work:
cmake_minimum_required(VERSION 3.9)
# ...
get_property(is_multi_config GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
if (NOT is_multi_config AND NOT DEFINED CMAKE_BUILD_TYPE)
message(WARNING "Must set CMAKE_BUILD_TYPE for single-config generators.")
endif ()
I'm using LINQ to SQL as my data access layer for a new project. I have added my database tables to the designer and all is well.
Whenever I use one of these classes in a function, Visual Studio warns me that 'Type xxxx is not CLS-compliant' or that 'Return type of function xxxx is not CLS-compliant'
Is this a problem with the classes that LINQ to SQL generates? Does it matters? Can I disable these warnings anywhere? My VS error list is clogged up with these warnings making it hard to see anything else.
EDIT:
Sorry, I should have mentioned these are VB.NET projects. :)
I found this link on MSDN Connect:
When adding inheritance relations
between classes in the O/R designer,
the acess level on the generated
backing store member of the Id
attribute, "_Id", is changed from
private to protected, causing the CLS
rule violation. The Id property is
used in an association between the
classes.
If you want to get rid of the warnings, you can use:
#pragma warning disable 3021
Or, if you want to disable them project-wide, add 3021 to the "Suppress warnings" field in the Build tab of your project's properties in Visual Studio.
Ben M has the right idea on the problem.
The quickest way to solve this on a VB.Net project is to make the assembly not CLSCompliant and hence avoid those warnings. Adding the following line to any of your files will do the trick
<Assembly: CLSCompliant(False)>
Best file to add it into is AssemblyInfo.vb inside of the "My Project" folder.
It ultimately depends on what types are being returned by your database and what the names of those types are.
One issue regarding CLS compliance is a type that has two publicly exposed members which differ in name only by case, e.g. MyField and myField.
Here's an article that should help you determine where your CSS compliance issues are occuring and deal with the issues. If you need more help, pose some code and we'll see what we can do.
I usually see that error when I'm consuming types from one assembly which does not have the CLSCompliant attribute in another assembly which does.
That is, are your Linq to SQL classes in a different project than the functions you're writing? Have you specified [assembly: CLSCompliant(true)] in some but not all of the projects in your solution?
I have VB.NET code in Visual Studio 2008 using an obsolete method and would like to suppress the warning. Unfortunately, following the recommendation is not a good solution, because it requires using a different class, which works differently, in important ways.
I'm trying to suppress the warning using System.Diagnostics.CodeAnalysis.SuppressMessage, but I don't know what to write as the parameters for the attribute and can't find any relevant reference.
I should also say that, right-clicking on the error in the error list I don't have any 'Suppress Message' option.
If you're using Visual Studio you can do the following.
Right click on the project and select "unload"
Right click on the project and select "Edit SomeProjectName.vbproj"
You should see two XML element tags with the name "NoWarn". Add the number 40000 to the list of numbers already present (make sure to do this for every NoWarn tag in the file)
Save the file
Right click on the project and select reload (you'll have to close the .vbproj file)
This will get rid of the warning. The number 40000 is the VB.Net error number for the obselete warning. You can suppress any warning in this fashion.
Note: If the NoWarn tag is not present, add it to the main PropertyGroup element with the following values
<NoWarn>40000</NoWarn>
In VS.NET you can right click on and suppress code analysis warnings. This will add the attribute for you.
However, the "don't use obsolete APIs" warning is not coming from code analysis, and so the SurpressMessage attibute won't work. This is a compiler warning.
For VS.NET you'd need to switch off this warning with...
/nowarn:0618
... at the command line (or just adding "0618" into the Suppress Warnings field on the csproj properties). You should do the same with whatever the VB warning number is.
I was able to resolve this with JaredPar's answer in my VB Project, thanks!
I did had same warning for my C# test project that I got removed by adding 618 in suppress warning section of Build Tab in Project Properties.
Please remember the Error Codes for VB and C# are different.
If one want to correct the these warnings then one need to install and use ODP.NET for Microsoft OracleClient Developers
Microsoft is deprecating System.Data.OracleClient, also known as Microsoft OracleClient. Microsoft OracleClient provider developers can use this opportunity to reevaluate which data provider to use for current and upcoming projects. Oracle recommends to start building new Oracle .NET applications with Oracle Data Provider for .NET (ODP.NET) and migrate existing applications to ODP.NET.
http://www.oracle.com/technetwork/topics/dotnet/index-085703.html