Warning: strpos(): needle is not a string or an integer in /customers/a/f/c/fjorden.se/httpd.www/joel/index.php on line 31 Warning: strpos(): needle is not a string or an integer in /customers/a/f/c/fjorden.se/httpd.www/joel/index.php on line 37 Blog by Joel Fjordén a.k.a. Will o Wisp
New Version of Code Style Enforcer 2.1.11 
Monday, June 4, 2007, 06:43 PM - Code Style Enforcer
Two bugs fixed in this minor release.

• Visibility rules settings not saved when changing them in tree view.

• CSE configurator application lost global rule settings for pages not visited.
3 comments ( 63 views )   |  related link

New Version of Code Style Enforcer 2.1.10 
Friday, June 1, 2007, 08:02 PM - Code Style Enforcer
I am now releasing a new minor version of Code Style Enforcer, where a fix has been made for an unfortunate bug in DXCore 2.2.2, which made Code Style Enforcer report invalid rule violations.

Besides this bug fix, there are some improvements coming from DXCore 2.2.2, namely experimental support for Visual Studio Codename "Orcas" and improved performance of the C# parser by approximately 30%.
8 comments ( 1080 views )   |  related link

Continuous Integration for Code Style Enforcer 
Friday, June 1, 2007, 05:20 PM - Code Style Enforcer
I have now made a quite impressive MSBuild script for Code Style Enforcer. The script upgrades version numbers for assemblies and setup files, builds assemblies, runs tests, builds setup, deploys setup, commits changes and creates a tag in subversion.

Cruise Control .NET is used for triggering the build when anything changes in the trunk and it also gives you a nice web dashboard with information about the builds. The Cruise Control Tray application is also good enough for instant status about the build process.

For a very nice tutorial about implementing continuous integration with MSBuild scripts and Cruise Control .NET, see this blog post by Carel Lotz from the South African .NET Developer Portal.

Visit the MSBuild Community Tasks Project for a lot of useful MSBuild tasks to include in script.

Hopefully this will increase the speed of Code Style Enforcer releases, which unfortunately has been rather low lately. I have made a small update though, which solves the bug in DXCore 2.2.2, described here.

So for all of those who are using the latest DXCore version, stay put, since there will be a new release this weekend!
3 comments ( 63 views )   |  related link

Bug in DXCore 2.2.2 
Sunday, May 27, 2007, 06:38 PM - Code Style Enforcer
Some users of Code Style Enforcer have complained about DXCore 2.2.2 together with Code Style Enforcer. There is actually a bug in the latest DXCore, which makes Code Style Enforcer behave strange and report invalid rule violations, e.g. visibility and interface implementations.

I have reported this to DevExpress and they will have it fixed for their next release. I am now trying to get an answer to when this will be. Until then and if possible use DXCore 2.1.3, which I know will work, or bare with me until the next DXCore version is released.

Read more about the issue here "http://community.devexpress.com/forums/ ... 84403.aspx".
1 comment ( 10 views )   |  related link

The CSEIgnoreRule Attribute 
Wednesday, April 18, 2007, 01:13 PM - Code Style Enforcer
I thought that it could be a good idea to inform you all of the CSEIgnoreRuleAttribute that has been around for some time now. We use it in our project and it is very useful for several reasons.

First of all it clearly documents the reason for violating the code rule, and thus avoids the problem of someone "correcting" it. It also makes the redline disappear from under the rule violation, since the attribute clearly specifies for Code Style Enforcer that it is a deliberate violation.

I will now give you an example of where and when we use it in our project. We demand that all interfaces should be explicitly implemented and for each thus method/property, there should be a matching method/property in the class marked as protected virtual. This makes it possible to override the implementation in derived classes and it also makes it easier and more direct to call local method/properties without the need to first cast yourself to that interface.

But sometimes the protected method/property must be public due to serialization or data binding and when we make it public it violates the explicit interface implementation rule. Therefore it is very nice to be able to clearly specify that we want/need to violate this rule, but it is deliberate, and we can specify why we did so.

In order to use the attribute you must add a reference to the CodeStyleEnforcer.Attributes assembly, which can be found in the normal Visual Studio reference list. Then simply add the CSEIngnoreRule attribute to the member that violates a rule and specify the rule type it is deliberately violating, i.e. Name, Visibility or Implementation. Make sure to also specify a reason for violating the rule.

Another very nice thing with the CSEIgnoreRule attribute is that it only exists in design time in Visual Studio. It never gets compiled into code and thus does not exist in the production code.
1 comment ( 11 views )   |  related link

Back Next