There are tons of good papers^[1] and a bunch of questions on StackOverflow^[2] about designing and developing for security, but all of them seem to concentrate on what you should do.

However, recently I was after something different: a "visit a page, try this and that" kind of things, you know. A list of simple actions one should to go through once development is done, to make sure the solution is secure.

Here's something I've come up with so far:
More...

I've been evangelizing the .NET platform for over 2 years, occasionally speaking (and listening) at venues from small local events to ponderously named conferences.

And let me tell you something: long presentations are not worth the time.
More...

In the previous post your humble correspondent introduced Riant plugin which allows you to specify restricted internal access for types and methods. (You say "method Foo should be accessible only within My.Name.Space" - and lo and behold, R# screams bloody murder if Foo is called outside that namespace.)

This post will shed some light on how to write such a plugin. Take it with a fine grain of salt - I'm not working for JetBrains and everything I know comes from Resharper community, other open source plugins, and protracted hours with Reflector.
More...

In C#, internal means that something is visible within the whole assembly but not outside.

Sometimes that forces developers to isolate components/APIs by marking them internal and putting them in separate VS projects within a single solution. Such undoubtedly creative approach has its benefits but also has obvious drawbacks: increased compile time, complicated deployment, etc.

Of course, there are other reasons for splitting code over several assemblies, but if your reason is stated above, a small ReSharper plugin that can help.

Head over to better life with fewer assemblies!
More...

By default, formatting for collection initializers doesn't look really neat with Resharper.

Just type some initializers or paste them from another place or reformat existing code - and here's something you will probably get:

var hmm = new NewYearHangover

            {

                Year = 2010,

                Place = new Place

                        {

                            Latitude = "40º 55' N",

                            Longitude = "21º 00' E"

                        },

                Memories = new Memories

                           {

                               Conversations = new[]

                                               {

                                                   "Philosophy", "Aviation", "Children"

                                               },

                               Fun = true

                           }

            };

However, you can easily make it less space-consuming. How about this:

More...

class One

{

    private static string me = "Am I different?";

}

class Two

{

    private static string me;

    static Two() { me = "Am I different?"; }

}

There's a certain confusion around static constructors. Why should we use them instead of static initializers? Any difference between the two samples above?

The rule of thumb is simple. If you want to control the time when CLR would initialize static fields, add the static constructor. If you don't care - skip it and use static initializers.

More...

My contract with the current employer prematurely ends in January 2010, so I've started looking for the next big thing.

If  your company is in EU and needs a .NET expert passionate about agile development - please drop me a line at andrew[AT]codevanced[DOT]net to get the CV and discuss the opportunities.

Interestingly enough, quite a few of my colleagues also have their contracts finished in January. So if you're looking for hiring a team of highly skilled professionals,  I'd be more than happy to discuss that as well.

Doesn't it look like Christmas has already started? Recently I had the pleasure of being contacted by Santa Claus Patrick Smacchia, lead developer of NDepend, who offered me a free Pro license.

(In case you don't know: NDepend is an awesome static code analysis tool to measure quality of .NET apps in a bunch of ways, including code metrics and bewilderingly abstruse, yet amazing, visualization approach.)

Woo-hoo! I remember playing with a trial version last year, which was kind of nice, but a free Pro is a free Pro. The offer didn't require a blog post in return, but very soon I realized that I cannot but post... because I'd picked up Resharper as a guinea pig.
More...