I recently set up the static analysis in VS2010 for one of my hobby projects (and annotated all headers), and some of the suggestions it made helped track down a few annoying little bugs.
Seeing that, I've been curious as to whether there is a more extensive rule set around or if such things are available anywhere (I'm using the "Microsoft All Rules" at the moment).
Are there additional rule sets that I could use; if so, where? (Google didn't find any easily)
If not (or even if there are), is there a better set to use? (my project works with graphics mostly)
I have written about 8, and may be writing more soon, if any of these interest you let me know.
Team policy reminder/enforcers
warn on calls to forbidden methods
GC.Collect GC.AddMemoryPressure
Messagebox.Show
warn if inheriting directly from Windows.Forms or Windows.Control
warn if a control or form subclass constructor does not call InitializeComponent()
warn if a control property is not set per team standards
DialogBorderStyle must be fixed
error if you do not override certain virtual properties (legacy from vs2005 designer bug)
error if you have code that raises a NotImplementedException
warn if you don't have hungarian notation to name controls
warn if fields are not private
ensure a project does not call a Config value or index that does not exist.
Also some of the code is found here
Related
How to filter Intellisense, Auto Completion, in Visual Studio C#, to show only members that the Project defined, or that are contained in the assembly from which I am currently editing code. Or that are defined in the actual class/interface that I am completing code one, and not the parent class?
Very often when I want to invoke/call/use a member that I defined. I am currently in a habbit of navigating to the class which I want to invoke a function on, copy/remember the name, then complete the code.
The thing is that I would find it very useful (in reducing redundant hand movement), while coding, to be able to view only the functionality that is written by me. Because in the environment that I am writing each object has at least 200 built in members that appear in most intellisense suggestions. And these built in suggestions are not part of my Assembly or Project. they are from the Engine. Similarly C# itself defines all these ToString() like members for each System.Object of which everything is derived from. To find the User-Defined members amongst all these System and Engine defined members is a hassle.
I searched google and forum for answers, to no avail. Also I don't have the money for solutions, so I would appreciate if it would be a free solution.
I afraid the answer is negative.
For now, IntelliSense cannot suppress the display of built-in properties, methods, and so on from the root cause to only show the custom parameter methods, and so on.
However, since VS2017, IntelliSense has only added filters, which can only be filtered by fields, methods, classes, keywords and so on.But you cannot filter by customization or built-in.
Suggestion
I suggest you put the class name, method naming specification(add some fields to prompt the method's role such as function select_AllManagers). After that, you can type a few more keywords to narrow IntelliSense down.
In addition, if you still want to get this point, you could report it to DC forum to raise the Support Team's attention. Hope this could help you.
With the risk to fall into too specific question...
Given a C++ MFC (mixed, not shaked) project compiled with /CLR, I have 200 classes already defined.
When I add a new empty class to this project, an error raises when I compile and execute in debug mode.
An unhandled exception of type 'System.IO.FileLoadException' occurred
in Unknown Module.
Additional information: Could not load file or assembly 'ProjectA,
Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. Could not find or load a type. (Exception from HRESULT:
0x80131522)
ProjectA is the name of the MFC project itself. There is no reference to any ProjectA assembly on project configuration, and there is no reference to another custom assembly.
This project only have references to some .NET Framework assemblies, in order to allow that some of custom defined classes in the project can use CLR classes.
Then, the question is...
Do you know whether there is any limitation of class number on a MFC C++ project?
EDIT:
As I say in comments, in release mode the compilation succeed without errors.
Also, I clean, build, clean, close Visual Studio, reboot computer... and the problem still appears.
If I keep in 200 classes, there is no error. When I go to 201, the error appears.
Currently I'm trying to reproduce in a new default MFC project, adding classes till arrive to 200, to confirm that there is a real limitation.
EDIT 2: ERROR FIXED
Great. #MSX and #frymode show me how avoid the error with his comments.
In the Visual Studio development environment (source / source):
Open the project's Property Pages dialog box.
Click the C/C++ folder.
Click the Code Generation property page.
Modify the Enable String Pooling (/GF) property.
Thank you guys!
The /GF hack is a known workaround for this problem. It is however not a correct one, you are putting a band-aid on a heavily bleeding wound. Pretty important that you heal the problem instead of putting a patch on it, this heavily affects the way your program runs at runtime as well.
The problem maker is the <Module> class, an internal class that the C++/CLI compiler generates. You can see it with ildasm.exe or a good decompiler. This class is required as a home for declarations in your program that are not class members, valid in native C++ but not supported by the CLR. Which demands that every variable or function declaration is a member of a class. The C++/CLI compiler solves it by moving such a declaration into the <Module> class.
There is however a limit on the number of members in a class, they are represented in the metadata of the .NET assembly with a metadata token. An index into other tables. The upper byte identifies the table number, the lower bytes are the index in the table.
You exceeded that limit. This is bad.
A problem with the /clr compile option is that it works too well. It is capable of compiling any C++03 compliant native C++ code to MSIL. Such code will be just-in-time compiled to machine code by the jitter, just like normal managed code. It is however not verifiable code and it doesn't act like managed code at all, you can blow up your program with pointer fumbles just as easily. And above all, it is not code that's optimized with the native C++ back-end. Only the jitter optimizer has a shot at improving that code, it cannot do nearly the quality job that the native C++ optimizer can do, given that it runs with a hard upper limit on how much time it can spend on doing that job.
Have a look-see with a decompiler to see what ended up in that <Module> class. That's going to be overwheliming at first, you know you've got a big one right now. You fix this problem by spending more time segregating the code into the managed parts and the native parts. Where the native code should be compiled without /clr in effect. It is a per-source file setting, you can even switch back-and-forth in a single source code file with #pragma managed. The simplest way to segregate is by keeping your native code in its own library or DLL.
This link shows that there's no limit to the number of types you can have in a namespace (not a project). Considering, that a namespace can be split across different assemblies, you could, at least in theory, have an unlimited number of types. However, this post affirms that the maximum number of classes in a .DLL
is 16777215. Probably, you'll run out of memory before you reach that number of classes :)
Just for information: there seems to be a limit to the number of fields per class, though.
P.S.:
Here's the solution to your problem taken from this link
Open the project's Property Pages dialog box.
Click the C/C++ folder.
Click the Code Generation property page.
Modify the Enable String Pooling property.
The XNA game that I am working on for WP7 supports multiple languages. However, something seems to be happening during the obfuscation process which seems to cause the language to always be set to English (the default language, in this case), at least according to the Resource class.
For example, each resource pack contains the following definition:
RESOURCE_IDX -> #
And each resource pack is given a different #. In an un-obfuscated build, the correct index is pulled out based on the device's current language. However once obfuscation occurs, the Resource class automatically selects the value associated with English even if the device is set to Spanish.
Is there a setting that I'm missing in the obfuscation process that is causing this?
It would appear that my issue was related to the renaming of the Resource class. That class is simply a set of auto-generated getters based on the contents of the resource packs. Somehow, subjecting that class to renaming during obfuscation caused the improper value to be returned (I won't speculate on why).
Once I prevented that class from being renamed, the rest of the application worked as expected.
I want to add usage statistics for a .NET 4.0 library I write on CodePlex.
I try to follow the step described here but my problem lies with the fact that what I write is a library and not an application.
One of the steps is put the Setup and Teardown attributes. I thought about adding the Setup attribute on a static constructor or a different place that will run once per usage of the library. My problem lies with the Teardown attribute that should be placed on code that ends the usage. I don't know where to put this attribute.
Is it possible to get usage statistics on a library?
Maybe I can register on an event that will fire when the application unloads the dll?
This looks like a typical honeypot giveaway, designed to commit you to the retail edition of their obfuscator. It's a tough business, few play this game better than Preemptive. Yes, using attributes is not going work for a library. The only possible candidate would be a finalizer. And you do not want your code to contact some website while the finalizer thread is running.
Take a look at the retail edition of their product. I bet it has a way to invoke the methods that are normally injected by their obfuscator directly. The class constructor is an obvious candidate for "Setup". An event handler for the AppDomain.ProcessExit event could be a possible location for the "Teardown" call. This also might avoid having to run the obfuscator at all, not undesirable in an open source project.
I'm pretty sure that previous versions of Visual Studio Code Analysis warned about the use of NotImplementedException, i.e. any member that contained this
throw new NotImplementedException();
would give a CA warning.
This doesn't seem to be the case with Visual Studio 2008.
Was that particular rule removed, or am I just imagining that it ever existed?
You are probably thinking about this FxCop warning that you get when throwing NotImplementedException from special methods such as a property getter, event accessor, Equals, GetHashCode, Dispose etcetera:
CA1065 : Microsoft.Design :
'SomeClass.SomeProperty.get()'
creates an exception of type
'NotImplementedException', an
exception type that should not be
raised in a property. If this
exception instance might be raised,
use a different exception type,
convert this property into a method,
or change this property's logic so
that it no longer raises an
exception.
However, it is not explicitly related to NotImplementedException. FxCop has white lists for the exceptions that may be (directly) thrown by these methods.
I don't recall ever seeing such a rule in the Microsoft-shipped rule set. It's one of the first custom rules I've created at the day job since at least the days of FxCop 1.35, so I'd have to guess that it harkens back to the days of FxCop 1.32 if it did ever exist...
I know this is an old question, but I'm getting this as a warning (12 Sep 2017), when running Code Analysis, using Visual Studio 2017. It is the "CA1065" code that Wim Coenen mentions, so it seems Microsoft must have ported FxCop rules to the Roslyn-based analysis platform.
Link provided in Error List window
Unfortunately, there isn't such a rule in the standard ruleset.
You can find my implementation of it in one of my other answers.