Visual Studio Taking an Idea From Eclipse?

Microsoft is now pushing Visual Studio as a full-featured tools platform, with benefits similar to those provided by Eclipse. Looking at the main landing page for Visual Studio 2008 you'll see a very prominent reference to the upcoming Visual Studio 2008 Shell:

Use Visual Studio 2008 Shell as the core foundation for your own software development tools.

Microsoft has always made Visual Studio extensible so 3rd parties can build add-ons and extensions to the IDE that can give developers capabilities that are missing from the the tool set included out of the box. But, it seems like the focus has been more on getting third parties to extend the functionality of Visual Studio than to provide a platform for tools development.

The Eclipse project has similar cababilities for extending existing tools based on Eclipse, but their focus is on providing a rich platform for all tools developers. As a result, the Eclipse platform is widely used for a wide array of non-Microsoft tools.

Cudos to Microsoft. Time will tell how this affects the tools landscape.

Don't Run Production ASP.NET Applications with debug="true" Enabled

You shouldn’t publish applications compiled with debug=”true” to production. This setting is useful during development, since when you do this the compiler generates extra debugging information to assist in debugging (i.e. debug symbols). As part of this extra stuff, the compiler generates .pdb files that contain references to the source files and line numbers. Some people might not realize that these are generated on the machine where the compile takes place, so these references will be to the files on your local machine.

Showing this information in a production application is definitely a bad idea for security reasons. But, this is not the only issue. I’m including a link to an article that explains why it's a bad idea to leave this on when publishing to production. It’s probably ok to leave this on when publishing to your dev/test servers, but the article also discusses how you can compile with debug=”false” and still get the debugging symbols to assist with debugging. That is probably the better option for dev/test.

Here is an excerpt from the article:

One of the things you want to avoid when deploying an ASP.NET application into production is to accidentally (or deliberately) leave the switch on within the application’s web.config file.

Doing so causes a number of non-optimal things to happen including:

The full article is here:
Don’t run production ASP.NET Applications with debug=”true” enabled

Security Education vs. Security Training

An excellent article from Microsoft discussing pros/cons of Security Education (i.e. university curriculum) vs. Security Training (i.e. job-specific skill training) and how both are necessary.

Here is an excerpt from the article:

There has been a lot of hoopla lately around "secure programming skills" – with not-so-thinly veiled condemnations of academicians and the role of the university in addressing the IT security problem...


The full article is here:
Security Education v. Security Training