Alexis Smirnov

Wednesday, June 25, 2003

Some new content on P&P site. This happens to be very relevant to some of the internal development underway in my team:

We have an ASP.NET application that makes a remoting call to an object hosted in OS service. It may take a long time to complete the call and we want to get the page back to the user quickly. Asynchronous Invocation Application Block

We want to allow administrators to edit .config files that are used by a running OS service without having to restart the service. We also want to use .config files to store encrypted connection strings. Configuration Management Application Block

Once we allow administrators to configure .config files on a live OS service, we want to make sure that parsing errors are reported to event log. Exception Management Application Block

I though it’d be a good test to see how practical it is to use those application blocks as oppose to simply code those features.

Monday, June 16, 2003

Weblog as a better bookmark:

I’ve noticed that more and more I’m coming back to my own weblog to get that pointer to a resource I wanted to check out, but didn’t have time. Here again:

Also out with a new release is FxCop, the code analysis tool that checks for conformance to the .NET Framework Design Guidelines. I'm toying with making this a part of my build process in the future. Note that there is not yet an SDK for this version, so you might want to hold off if you need to write your own rules.
Agile Build Engineering - new Wiki hoping to cover the areas "where Agile Software Development and Build Engineering collide." [Larkware]

Friday, June 13, 2003

[MSDN]: Improving Web Application Security: Threats and Countermeasures Roadmap

This guide gives you a solid foundation for designing, building, and configuring secure ASP.NET Web applications. Whether you have existing applications or are building new ones, you can apply the guidance to help you make sure that your Web applications are hack-resilient.

Stating the obvious, Patterns & Practices section of MSDN consistently delivers some of the most solid content of entire MSDN site.

Chris tells us about of Longhorn API review and in the process, lists some generally useful design guidelines that can benefit any .NET development team. It seems that API review is not a peer code review because it is done not by people involved in actual coding of a component. It’s not a design review because the team focuses on interfaces as oppose to their internal implementation.

Here’s my takeaway:

The team building the API had answers a standard questionnaire from the review team, which includes:
- target users
- potential security problems
- representative sample code that users would be expected to construct.

Specific advice from reviewers:
- use best practice coding conventions in sample code
- support IDisposable at a macro level instead of a micro level
- expose collections from properties returning IEnumerable (not from the parent object itself)
- prefer properties over Get/Set methods (as appropriate)
- don't tack the name of the enumeration type onto the enumeration values themselves
- prefer overloads to parameters that can be null
- prefer typed parameters to object parameters

Points above seem to be aligned with these guidelines.

Thursday, June 05, 2003

Nikhil (architect of Web Matrix) posts the sample code for HTML viewing and editing component. Something like this must be part of Web Matrix code base anyway. Speaking about it: “Web Matrix wasn't built by a formal team at Microsoft -- but rather by a group of people across the ASP.NET team who worked on it in their spare time (mainly nights and weekends). “

How cool would it be to see all of Web Matrix code released?

Thursday, May 29, 2003

Introduces new COM+ 1.5 features and offers design guidelines to take full advantage of these new capabilities in .NET applications. [MSDN: .NET Framework and CLR]

COM+ 1.5 ships with Windows XP and Windows Server 2003, but this article looks like a good read even if you�re targeting Windows 2000 (with COM+ 1.0). It talks about the quirks of using COM+ services from .NET.

Wednesday, May 28, 2003

There�s a discussion going on the NUnit mailing list about where to put unit testing code. This important question needs to be answered by any project team before embarking on unit testing bandwagon in the context of medium-to-large scale project. Here�s why:

Developing unit tests will end up taking a significant amount of team�s time and will result in significant amount of code. As with any other development and coding guidelines you want to have clear guidelines with respect to organization of unit testing to avoid chaos and confusion. You will want to make it easy for every developer to introduce a unit test � not more difficult than introducing any other piece of code. Finally, you will want to be able to strip unit testing code when you prepare a distribution package of your product. You will also want to exclude NUnit binaries from your distribution package.

My team has spent some time pondering the following alternatives:

Put all the tests in a separate assembly. The idea here is to have a single assembly that would depend on NUnit binaries. When shipping the product this test assembly would be left out of the distribution package. That�s easy. The drawbacks of such solution are that you�ll end up creating a big assembly with lots of tests. This assembly would end up depending on lots of �production� assemblies. The source control of this central test assembly would be problematic since many developers would often need to make concurrent changes to it. Unit tests would have to be limited to public interfaces of production types. We have dismissed this idea because of these drawbacks.

Create a satellite test assembly per each �production� assembly. In this solution it is equally easy to create nunit-less distribution package. It becomes easier for developers to add new tests and not step on each other those in source control. The trouble is, would still be impossible to test internals of production types. This solution would also make the project have twice the amount of assemblies you�d normally need. Source tree and build management issues usually grow with the number of assemblies you have to manage. We have abandoned this idea too.

We�ve ended up the following: Put tests together with the production code, but make them separate. The idea here is to put all unit test code in the same assembly along with the production code, but be able to separate the unit-testing code when building the distribution package. We put all the unit-testing code in the separate namespace just below the namespace of the production code. A namespace MyCorp.MyProduct.MyComponent will have its tests in MyCorp.MyProduct.MyComponent.Test namespace. Furthermore, all the unit-test source files are located in the separate test directory (Test) under the directory that holds the production code. The same Test directory usually holds data files needed to run the tests. This organization solves all the above issues, but makes the generation of test-less distribution package fairly easy as well and makes XML based build files (like NAnt or VS.NET) really shine. Since the organization of test files follows strict rules, nant build files can be changed using XSLT to exclude ./Test/*.cs files from the build. The dependency can also be excluded by the same transform. This solution represent a little bit more work for build-master, but saves a lot of hassle for developers. (I�m not posting the XSLT transform because we don�t have it yet. But stay tuned :)

Friday, May 23, 2003

Not long ago I�ve talked about a utility called xsd2db that we use to create a database schema directly from .XSD files. A few people told me they about different scenarios where such tool could be useful. John writes re-writing Pet Shop using code-generation tools. To me, it looks like xsd2db could help.

So to put the bits where my mouth is, I�ve created a project on SourceForge to share the code and let others contribute.

I know this initial release works in our environment (.NET 1.0, Sql Server, VS.NET 2002). But there�s plenty of room for improvement of course. The utility can easily be extended to support other databases (Teradata is next on our list). 0.1 version can only create new databases from scratch. A neat feature that would be nice to have is the ability to merge existing database schema with .XSD file. In other words, being able to update (refactor?) existing database schemas using XSD. Comparing a DB schema with a given XSD file is another useful thing to have. It is all about unifying relational and object-oriented data structures. What do you want xsd2db to be? Who knows how far this experiment will go.

As added benefit it gave me a chance to compare SF projects with GDN workspaces. Early results: 10 minutes to set up GDN workspace. 2-3 hours to figure out SF and CVS setup. Needless to say SF/CVS combination is clearly more powerful platform with much more features than GDN/VSS, but it comes with a bit of a cost.