I have a .Net project in which some classes (e.g. constants, enums, etc.) are generated by a tool developed in the company. Developers would not participate in changing them. In addition the team using this tool may make mistakes due to the large size of the project.
Is there any way I can enforce some rules like folder structure, naming, proper namespaces, and such things upon inserting those files in the solution? Or is there a way to test these factors?
To enforce a folder structure, you could add custom logic in MSBuild. The logic in MSBuild would run as part of a build. If you know that certain folders must exist as part of a project and/or that certain files must be in certain folders, you can add verification steps in MSBuild and either issue a warning or stop the build with an error.
To enforce name and namespace rules/conventions you can use a static code analyzer. You can use the Microsoft Code Analyzer and/or a third party analyzer. If the 'rules' you need are not available out of box, you can write custom rules.
Both the MSBuild and code analyzer can be used with and without the Visual Studio IDE and can be used locally and in automated builds.
What I seek is achievable with ArchUnitNet. It can be reached here
It helps with testing the folder structure of the project as well as namespace testing and relative naming and even correct inheritance if I'm not mistaken.
Related
Suppose I have a bunch of namespaces:
SuperNamespace.namespace1
SuperNamespace.namespace2
SuperNamespace.namespace3
SuperNamespace.namespace4
...
SuperNamespace.namespaceN
Each namespace has its own project and each project creates its own dll file:
SuperNamespace.namespace1.dll
SuperNamespace.namespace2.dll
SuperNamespace.namespace3.dll
SuperNamespace.namespace4.dll
...
SuperNamespace.namespaceN.dll
I like this design because it allows developers to use only the code that they need. Sometimes having a bunch of dll's can be a bit cumbersome and annoying. I would like to create a SuperNamespace.dll which contains all of the namespaces. That way, a developer has the option to use what he/she needs or just take the big dll file, i.e. SuperNamespace.dll containing all libraries:
SuperNamespace.namespace1
SuperNamespace.namespace2
SuperNamespace.namespace3
SuperNamespace.namespace4
...
SuperNamespace.namespaceN
Is there a way to do this in a C# Visual Studio 2010 solution?
I would simply create one large project with all sources unless there are other reasons to keep separate assemblies.
In later case I'd still create one project that includes everythin in addition to small projects before going ILMerge route as Mith Wheat suggested. You can easily create new project from a lot of files using File->New project from source (may need higher version of Visual Studio for that, defintely not Express ones).
There is no restrictions how many C# namespaces can be used in in one assembly (DLL). You can find many examples in .Net framework itself - i.e. many of System.* namespaces come from the same assembly.
Opposite is true also - same namespace can come from multiple assemblies.
Note that in compiled code there is no such thing as "namespace" - it becomes part of class/struct/enum name.
I am trying to build a NSpeex solution for Windows Phone application. The problem is that a codeplex NSpeex page provides a Silverlight version of the library, but it throws a run-time exceptions, since the code contracts are used in the library, that are not yet present in Silverlight for Windows Phone.
I will go ahead and remove all the lines of code that make use of Contract class. For this I will just do a text search on all the classes in the Visual Studio Project. Is there a better solution. For example, to somehow prohibit the use of some namespaces, so that the VS compiler would show me all the dependency points?
I haven't looked at the source code for this project, but what we usually do in this situation is to either build stub classes that stand in for the missing classes (especially if they are attributes) or remove code through conditional compilation.
The decision on which approach to use depends on the complexity of the problematic code.
In .NET and Visual Studio projects, the convention is to let the physical directory structure of your project resemble the namespace structure of the project. I totally agree with that, and every time I work on a project that violates this guideline, I have trouble finding types, because it's often unclear how to navigate the namespace hierarchy.
A problem I encounter however is that wrapping every class in a namespace is redundant, when using this guideline. Furthermore, it makes it very hard (without commercial refactoring tools) to restructure the project structure later on, because every file needs to be changed.
I believe that moving classes to a different namespace should simply be a drag 'n drop of that file in another directory.
So how can we accomplish this? Is there a way to let the compiler (or any other tool) determine the namespace my classes (during compile time), based on the directory structure of my project?
Resharper can detect namespaces in code which do not match physical layout. Unfortunately Resharper is not cheap.
AFAIK the C# compiler has no knowledge of any relationship between namespace and physical location and therefore has no such options available.
IMHO this should be built into Visual Studio.
I have several class files in App_Code in an ASP.net website running in Microsoft Visual Studio 2005 Professional.
In liu of using a full unit test suite I just want to somehow compile those project-wide classses into an .EXE so that I can nightly run unit tests on them.
I do know how to create a separate C# library project consisting of those files and how to include them into my website--but that is not desirable--I don't want to give up the ability to make on-the-fly code changes of those library classes when running the website in the debugger. As far as I know .Net debugger isn't powerful enough to modify code in included libraries with instant auto re-compilation on page re-load.
So, I want my cake and eat it, too:
Command-line unit testing of website class files in App_Code directory
Being able to modify those class files w/o stopping/re-starting the web debugger.
Is it possible to have both?
You should put the code in an altogether separate class library/assembly, then reference it from your web project and the command-line utility. As far as I know, it makes no difference where you modify your code, when stopped in the debugger. Never had problems myself.
Hope that helps.
Your project is under source control, right? Right? In that case, you can use your source control system to include a link to your asp.net project's app_code folder as part of a separate unit testing project. The exact linking mechanism varies by source control platform, but done right it means there's exactly one instance of your App_Code folder in source control that's visible from two different projects. This way, everything stays up to date.
This has the advantage of allowing you to keep easy, uncompiled code right there just like you always have, but still making the code available for testing.
I wonder if people (meaning the company/developers) really care about having [SuppressMessage] attributes lying around in the shipping assemblies.
Creating separate configs in the Project files that include CODE_ANALYSIS in Release mode and then yanking it off in the final build seems kind of an avoidable overhead to me.
What'll be the best stratergy, if one does not want these to remain in the final assembly but still want to use them in code ?
and Is there any advantages/disadvantages of storing them in FxCop Project files ?
[I'm coming from a VS2008 Pro+FxCop 1.36, rather than VS2008 Team System]
The SuppressMessage attribute will only be added to your code if the CODE_ANALYSIS preprocessor definition is present during a compile. You can verify this by looking at the definition of the attribute in Reflector.exe. By default this is not defined in Release so it won't affect production code.
Typically, I only run FxCop on DEBUG builds of my assembly where CODE_ANALYSIS is defined.
In the grand scheme of things, I don't think it really matters. Since this is an attribute (effectively meta-data), it doesn't impact code performance. That being said, do remember that the information in the attribute is available to anyone using a disassember like Reflector.
The problem with storing them in the FxCop project file is that you must then ensure that everyone uses the same project file and that the project file always travels with the project (it's checked in to source control, which means you must check it out each time you want to run FxCop).
If you don't want the SuppressMessage attributes in your production code you would need to only define the CODE_ANALYSIS symbol in the build you are running FxCop against. This does mean defining it either on your Debug configuration or adding additional configurations. The attributes will only be compiled in to the code when the symbol is defined.
From an automated/nightly build viewpoint, you can build using a configuration that has the symbol defined and then build the production release without the symbol or do two builds - one with the symbol defined, run FxCop to get your violations, and then another build without the symbol defined.
We have a ton scattered around production code, and we don't particularly care. It doesn't effect perf, and having some crufty looking attribute in a class often gives motivation to remove it if at all possible.