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...

A few days ago my workmate Ian made a point that there should be a nice way to implement type safe route registration in ASP.NET MVC.

Type safe! Can anyone read these words without experiencing a tug of excitement, without being swayed by the view of departed bugs and newly arrived refactorings on controllers and actions - refactorings that don't break your app?

Indeed, type safe is possible. Here's how we register our routes now:

routes.MapRoute(

    "viewProduct",                                                        

    "{locale}/{product}/view/{mode}/",                                 

    new { controller = "Product", action = "Display", mode = "full" }  

);

routes.MapRoute(

    "{locale}/{product}/view/{mode}/")

     .On<ProductController>(x => x.Display("full"));

var zipCode = order.Customer.Address.ZipCode;

• don't reveal too much of yourself to others. Do not mark things public if they can be private (or internal, etc), avoid putting several methods of a similar purpose on your public API, avoid global data (and avoid singletons - if feasible - because they are global).   
• don't interact with others more than it's necessary. Basically, call as few methods as possible. Methods with smaller response set (response set is a number of functions/properties called by a method) are less prone to error and break less frequently, as they're less coupled with the rest of the system. 

More...

Most of us would agree with Christopher Alexander, that the central task of architecture is creation of a single, shared, evolving pattern language. And pattern language does not necessarily mean a suite of general ideas.

It can be anything: a development framework, or a set of APIs, or a pool of reusable artifacts. In either case, clarity and usability is that what matters. Hey, it's a pure darwinism: struggle for existence and natural selection. The more people choose the artifacts you create, the better those artifacts spread, and the longer they stay.

That's why one of the most significant jobs of an architect is to create appealing artifacts. Those that developers will use correctly and will want to reuse. Those that are easy to understand, adapt, evolve, and explain to others.

Let's look at the following piece of .ascx.cs code ^[1]:

///<summary>

/// 0 - parentId,

/// 1 – postbackUrl,

/// 2 – container,

/// 3 – default uploader

///</summary>

private const string template = @"{0} = new Uploader ('{0}','{1}','{2}','{3}');";

...

string script = string.Format(template, ClientID, ...);

AddJavascript(script);