June 2003 - Posts
has a thing or two to say on how best to use FxCop
Alex Lowe last month posted a well thought out, rather calm and relaxed rant on Microsoft's apparent lack to dominate the market for tools that support software development on .NET.
Having spent the past two weeks designing a build process for a client of mine, I must agree with everything Alex has to say 100%! Well worth a read.
If you create a file called app.config in your VS .NET project, that app.config folder will be copied to the output folder (e.g. bin\Debug) and renamed target.config, e.g. MyApp.exe.config.
That's a great way of getting .config files into SourceSafe without having to reference the output folder, and a good way of pushing .config files around in developer teams. Its also a good way of confusing otherwise seasoned developers if they don't know it does it!
Ever had one of those "I'm sure there's a command line util to do that" feelings about the .NET Framework Tools in the SDK?
This helpful MSDN article lists all the tools, and is substantially less cryptic than dir /p.
I've been tripped up by this one many, many times! For those of you who are really into your attributes (as I am), the AllowMultiple property is useful for when an attribute has to be applied to the same class definition multiple times.
By default, AttributeUsage's AllowMultiple is set to false, meaning that you can only decorate a type/member with a given attribute once.
Here's the exceprt from Patrick Steele's blog which explains further:
I had designed a custom attribute for fields and wanted to be able to apply it multiple times. For example:
<ExtItem("A1", "Text"), ExtItem("A2", "Color")> _
Private label1 As System.Windows.Forms.Label
This produced an error: Attribute 'ExtItem' cannot be applied multiple times. A quick check of the documentation says "multiple instances of an attribute can be applied to the same target element". So what was I doing wrong?
Fellow MVP Mattias Sjogren pointed me to the AttributesUsage attribute:
<AttributeUsage(..., AllowMultiple:=True)> _
Public Class ExtItemAttribute
This reminds me of another attribute-ish point. Thanks to FxCop for pointing me to this one. Apparently, attributes should be declared as "sealed". There is a significant performance degredation when using non-sealed attributes (although to me .NET reflection is so fast, I've personally never seen this particular problem).
This is one of my favourite .NET blogs so far. Suzanne Cook
posts some excellent low-level CLR bits and pieces.
Jeremy pointed me in the direction of an article by one Tim Dawson about Hosting Windows Forms Designers. I did this about a year ago in some prototyping work I did for a client, and it was quite tricky to work out at the time. This is a nice round-up of how you did it.
Tim's site also has a number of cool controls available for download as well.
Worth a look.
I wanted to get hold of SLiNgshoT yesterday - this being a project that converts VS .NET solutions to NAnt build files. SLiNgshoT is part of NAntContrib which are plug-ins for NAnt.
(VB .NET users - note that SLiNgshoT only works with C# projects.)
Faced with a lack of a download link, I figured I could download a file from SourceForge's CVS repository. Thanks very much to Jason Alexander who directed me to TortoiseCVS - a plug-in for Explorer. This means those of use that can't remember how to use a command line interface don't need to tax our brains too much...
Here's an interesting article on the Windows 2K3 vs. WebSphere on Linux/Unix.
To blatantly copy bits of the abstract:
Overall, @stake found that:
- Both platforms provide infrastructure and effective tools for creating and deploying secure applications
- The .NET Framework 1.1 running on Windows Server 2003 scored slightly better with respect to conformance to security best practices
- The Microsoft solution scored even higher with respect to the ease with which developers and administrators can implement secure solutions
As a result, @stake recommends that:
- Development organizations that are experimenting with Microsoft Windows Server 2003 and .NET Framework should not allow security concerns to hold back deployments
- Companies that have made strategic commitments to either platform need not switch solely on the basis of security
- Companies seeking to standardize on a web application platform will derive significant security benefits from both, but may find the Microsoft solution easier to secure initially
I personally like "Development organizations that are experimenting with Microsoft Windows Server 2003 and .NET Framework should not allow security concerns to hold back deployments", as it certainly mirrors my own beliefs about .NET.
Well, this was news to me - but maybe not for you as SharpToolbox has already been posted by Fabrice here.
I think this is a great idea. What I particularly like is the fact that I can subscribe to an RSS feed of new tools that he's added to the catalog, or updates to existing tools.
More Posts Next page »