The big Microsoft announcement is out at MIX. Microsoft has formally announced support for IronPython and IronRuby, as well as more goodies for SilverLight.

Also, SilverLight is now in GoLive licensing -- meaning we can officially release software for it. (if you happen to have some laying around right now)

You can read the details at Soma's blog.

SubSonic 2.0 is released

I still like this project -- even tho I haven't had a chance to really use it yet.

You can check it out and the new feature list at Rob Conery's web site.

Or just download the thing from CodePlex.
Note: their CodePlex web site now says: SubSonic: All you database are belong to us.

Also from SubSonic's CodePlex site, this is what SubSonic is:

About Subsonic
SubSonic is a toolset that helps a website build itself. At it's core it's:

• A Data Access Layer (DAL) builder that requires no code on your part, it builds itself at compile-time with a full object layer and strongly-typed collections
• A complete utility toolset, complete with Rails-like scaffolding, migrations (DB Versioning), and code generators
• A dynamic query tool, that lets you use SQL Server and the Enterprise Library without having to know SQL
• An OR Mapper that extends to views and stored procedures so you're not locked into the OR/M thing

What SubSonic does for you:

1. Trim hours from your DEV cycle. This not only happens because the code is generated for you initially, but it's also maintained by SubSonic whenever you change your database.
2. Gives you the option to go full-tilt OR/M, or use SPs/Views. We don't want to tell you what to do, you already know best. We just want to help.
3. Help your application build itself. With our generators (class, scaffold, and batch-class) your site can build itself in no time. The scaffolding will help you work with your data quickly.
4. A solid foundation from which to extend. Our starter site comes pre-wired with ASP.NET membership built in, AJAX, full 3-column elastic XHTML theme, and user administration pages from which you can administer your site's membership. That's at least a week's worth of work - already done!
5. Get your project from idea to prototype in a fraction of the time. That's the strength of this project - using our starter kit you can have a sharp prototype up and running in the merest fraction of what it used to take.

Debugging an ASP.NET Web Site with SSL

Here is another fun one, and a follow up to my last post.

We are developing a ASP.NET Web Site that needs security. So we add a SSL Certificate to IIS and go. But, debugging with that pesky "https" prefix is a little harder.

The problem is that when you debug an ASP.NET Web Site you are using Cassini as you web server by default. You can go to Project->Properties->Start Options and tell Visual Studio.Net to launch with a "Custom Web Server" -- but that only works if you are using NT Authentication. We not.

So by default, you cannot debug as ASP.NET Web Site with an SSL certificate in use. Unless you know of a back door. (If I was using sound effects, I would have a drum role right here).

First you should know there are two types of web projects: ASP.NET Web Site and ASP.NET Web Application. The ASP.NET Web Site is new to .Net 2.0 and there are a number of differences between the two project types. You can look up most of them later, I'm only interested in one difference.

In the ASP.NET Web Application, when you go to Project->Properties->Web tab, you can specify to debug with the IIS Web server. You can even tell it which Url to use. So if your url is normally "http://localhost/MyWebApp" you can change it to "https://localhost/MyWebApp" and viola!, you are debugging a secure web site!

OK, but our current web application is not a ASP.NET Web Application, it is a ASP.NET Web Site, and I don't get that option -- but I still need to debug the web site with the certificate. Now I'm getting to the back door.

First note: to do this, your existing application must be a Web Application in IIS.

First off, don't change your project type, leave your existing web application as is, no changes. Create a new ASP.NET Web Application, call it DebuggableWebProject (or something like that). It should be created with a Default.aspx page. Make the changes I specified to the properties pages I specified up above. Also register the web site with IIS; if using IIS7, both web site must be part of the same application pool. The run the web site from Visual Studio.Net in debug mode.

Next, from your new web site in Visaul Studio.Net, open one of the code files (either .cs or a .vb). Set a break point somewhere obvious. Then open up your web site in IE/Firefox using the SSL address (https://localhost/MyWebApp/...) and hit a page that should go thru the code you set the breakpoint in and the breakpoint should catch.

That is basically it. You create a second web project to debug your existing web project. That is your back door. It is a little strange, but it works fine. It even allows you to debug a secure web service call.

Anyway, I found this by accident and I hope it helps someone else along the way. Also note: I am using IIS7 Visual Studio.Net 2005 and have not tested this with IIS6 or any other version of Visual Studio.NET. But it does work in both Integrated and Classic mode application pools in IIS7.

Using secure WebServices

One of my projects these days is developing a WinForms application that talks to a server via web services. Pretty standard stuff.

I finally got to the "Secure web services" task. No problem, also pretty standard stuff. And it is...if you can find the info.

First step: Secure your web service with an SSL certificate. If you are developing on Vista and using IIS7 -- congratulations, you get this for half price. Go see ScottGu's article titled: Tip/Trick: Enabling SSL on IIS 7.0 Using Self-Signed Certificates

5 minutes later -- step one complete.

Step two: check my application to see if everything still works.

5 minutes later -- utter failure!

The app blows up all over the place. I act like this is unexpected, but it isn't. You can't make a change like that without a few casualties. When you sign onto a web site with a certificate you are usually asked if it is OK to accept said certificate. But I aint writing a web browser, I just want to accept the certificate (if there is one) OK Google, don't fail me now...

Anyway, after some searching I found a nice post by some guy named Jan at http://weblogs.asp.net/jan/archive/2003/12/04/41154.aspx
where he talks about the problem.

I go to implement it and find out the method calls he is using are obsolete as of .Net 2.0.
The old method to use was System.Net.ServicePointManager.CertificatePolicy.
The new method to use is System.Net.ServicePointManager.ServerCertificateValidationCallback

By the time I had found that I had, once again, given up on Google and gone straight to MSDN Forums. Actually, I was using MSDN's search feature -- but luckily it also searches the forums.

So anyway, if you are looking to accept a cert on your client app here is some code for you.

// add this to your code before you make your web service call.
System.Net.ServicePointManager.ServerCertificateValidationCallback +=
delegate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors sslError)
{
bool validationResult = true;
return validationResult;
};

BTW, has everyone noticed that you can now add information to MSDN? Very cool. I added this code snippet to the MSDN documentation -- just in case they don't read my blog.

ReSharper 2.5.2 is out

I missed this one for two days before seeing it.

JetBrains has released a new version of their Visual Stuido.Net add-in ReSharper with a health bug fix list.

It is a great tool, but if you dont have it and can't afford it, do check out their unit testing addin called UnitRun. It is free and well worth the download.

Visual Studio "Orcas" and .NET FX 3.5 Beta1 shipped!

Visual Studio "Orcas" and .NET FX 3.5 Beta1 shipped!

You can read about it on Soma's blog.

Or go right to the MSDN page.

I'm sure there will be more on this later.

WPF/E = Silverlight

OK, this is a first. Microsoft takes a crummy, unmemorable name like WPF/E and turns it into something interesting, like Silverlight.

Granted, some people still aren't going to like the new name, you can't please everyone, but I like the direction.

Read more about Silverlight here:
http://www.microsoft.com/silverlight

Or on Soma's blog.

ProClarity via MSDN

For all of you with MSDN subscriptions, you should now be able to download the ProClarity product line from the MSDN web site (version 6.3).

No word on whether Microsoft will mail out CDs...but is that really that important anymore?

Personally, I think this is wonderful news. Anything to get a wider base for ProClarity is good by me.

Do note: I am a former ProClarity employee, I'm sure there is still a fair amount of my code running around the desktop product...and I'm available for consulting! :)

HNibernate: Many-to-Many Joins

OK, this one has waisted a few too many hours for me and another developer here in the office. Resolving many-to-many table relationships in NHibernate.

Note: last time I blogged on NHibernate I was told things were easier with ActiveRecord. But I'm still not using ActiveRecord.

I will set things up first. Here is our table layout and relationships:

If you can't see the image, there are three tables: TableA, TableB, and TableC. TableA and TableB both have relationships to TableC. A classic Many-To-Many table structure.

Now the first thing you have to decide is which table leads. Or which table is the master. That table will take care of actually adding and removing items from TableC. I will use TableA.

So in TableA's hbm you will have an entry that looks like this:

<bag name="TableBs" table="TableC">
<key column="TableA_id">
<many-to-many class="MyNamespace.TableB, MyNamespace" column="TableC_ID">
</many-to-many></key></bag>

and in the TableA class (this is C# kids), you should have this:

private IList<tableb> _tableBs = new List<tableb>();
public virtual IList<tableb> TableBs
{
get { return _tableBs ; }
set{ _tableBs = value; }
}

Ok, TableA is now setup as the master. Now to make TableB the slave.
In the TableB hbm.xml you will now see this

<bag name="TableAs" table="TableC" inverse="true">
<key column="TableB_ID">
<many-to-many class="MyNamespace.TableA, Aim.Domain" column="TableA_ID">
</many-to-many>
</key></bag>

Then the TableB class

protected IList<TableA> _tableAs = new List<TableA>();
public virtual IList<TableA> Contacts { get { return _tableAs ; } set { _tableAs = value; } }

It would be easy to miss the difference between the two, so here is the difference. In the TableB hbm there is a "inverse="true"". That is the only real difference, but it is a critical change to make if you want to be able to modify what items are related to what.

Is window development dead?

There are debates going through the internet right now about whether or not Microsoft is dead, and by association, rich-client development.

Disclaimer number one: I am biased. Over 50% of my work these days is still rich-client. I love creating rich-client applications. Something about only having to work with one language to create an application (instead of three or four) still makes me smile. Being able to finely control threading, painting, and events without worrying about session state and callbacks is downright wonderful. I think rich-client applications will be around for a long time now -- even with AJAX readily available.

But the nature of rich-client development has changed. It used to be normal to create stand-alone applications that happily (or unhappily) sat on a users machine and did their work without a care in the world. That world is gone and the internet killed it. No worries, it needed to die -- or bleed a bit anyway.

I have not written a rich-client application in the past couple of years that did not have some internet capability. Either calling web services for data, checking for updates, or just scraping web pages for content, everything is internet enabled. As it should be.

The thing is, I do have friends who believe that rich-client is dieing and and all development will soon be centered on web development. And truth is, a good chunk of the collective brain power is being spent there. As it should be. Web development still has some catching up to do.

Lets state the obvious with web development.

• Debugging Javascript: Ugly!
  
• C#/VB.NET, Javascript, XHTML, CSS, XML, SQL: I have a sinking feeling.
  
• Debugging regular code: Could be better.
  
• Model-View-Presenter: REALLY Ugly.
  
• Number of technologies needed: a dependency nightmare.
  
• Deployment: as painless as debugging Javascript on 10 different browser/OS combinations can be.

Rich-client also has its faults, some are greater than the web development. As much as a pain web deployment is, Rich-client deployment is a nightmare where every client machine is a monster lurking -- and so far I have seen no technologies to fix that. Theming a rich client app is something best left to the professionals.

Unless...WPF turns out to be all it is cracked up to be. In that case, the theming argument goes away muttering to itself. I have great hope for WPF. In fact, WPF is the reason I think rich-client development is not dead and could be heading for a renaissance.

This could be the first time designers will really have to the chance to do something. All of those cool UI's that you see in games are entirely reachable now. The chance to make something beautiful is very possible, just like the likelihood of creating something extremely wretched (I'm still waiting for the first WPF app to come out and show the world what not to do). That is the beauty of rich client development now, the possibilities. I love the feeling that the sky is the limit and anything I design I can do.

I still don't get that from web development. From a design standpoint, it is both more open and more restricted than rich-client. It also feels more brittle (in a code smell soft of way). All of those technologies stitched together to make a ducted-taped whole. It really isn't all that cohesive. You don't believe me? Read the technology list from above again and get back to me.

So is rich-client development dead? In spite of what any die-hard web developers might tell you -- no. In reality, both development types, rich-client and web, will continue to exist and learn from each other. They will continue to integrate. But they wont be the same for a very long time.

If ORM is so great, why isn't everyone doing it

(Note: Ayende corrected corrected me on this one. Using active record you can get rid of the mapping file and "decorate" your class with attributes that NHibernate will read instead. I should have mentioned that, I did know about it, we just are not using it yet in our current project.)

Add to that title: 3-tiered architecture, Test-Driven-Development (TDD), Mocking, and the Carpel Tunnel Pattern (Model-View-Presenter/Model-View-Controller).

The answer: because it it a lot of work. A "scary" it's a lot of work. A "I can't believe you are doing this" lot of work. And if you are a one man shop: quadruple that. This is probably the same reaction that the Oregon Trail settlers had when they saw the Rockies. Big tall mountains, standing right in between them and where they wanted to be. So big that there was no way to see the other side. The difference is, the Oregon Trail settlers KNEW there was another side. A promised land, as it were. Of course, if they new better they would have headed for California instead of Oregon -- but that is another story. The same is true for all of these technologies. They are a lot of work to implement -- at first. But once done life gets a lot easier.

Compare that with all of those spiffy RAD (rapid application design for those of you who have not seen the term in a long time) demos that EVERYONE is giving. Microsoft, Borland, et al, they are all to blame. The demos that usually start with "Now watch as I make a complete databound application in 10 minutes complete with every wiz-bang feature that you don't implement in your app and customers don't care about." They are quick, seam easy, and relatively painless. But they dont show that as your application grows in complexity, things often get much worse for the RAD tools. Your code quickly turns into a disorganized mess. All of your code is in a couple of files (often one) and finding anything is a herculean task.

If time is money, you still get what you pay for.

I will use NHibernate as an example. Right now, in the world of ORM tools, NHibernate is a 400 lb strong man with a weird accent that makes him hard to understand. You know he is powerful, but the language barrier makes him hard to deal with at first (both my grandfathers were like that). But once you muscle through that initial frustration it is amazing the things you can get done.

The language barrier in NHibernate's case is its strange API, the HQL language, and the metric ton of classes and configuration files you have to create. In the system we are using, there are 2 or 3 files created for every table in the database. One data class, one XML configuration file that maps to the data class, and another class that has all of the strange HQL queries. (Note: this list of classes can be reduced by one with Active Record, and you can use one class for all of your HQL queries). Then there is a class for working the data and giving to the presentation layer, then the presentation layer class to display the data. No wonder there are no good samples on this stuff (and I call it the carpel tunnel patter for a reason). Plus, I haven't even gotten to the test classes yet!

That is a lot of work to implement. Even when you know what you are doing that is a lot of work. But as with many things, the time is made up later. Notice there is no confusion about where the database queries go. There is no confusion about what classes hold the data. And there is no second guessing about putting the queries in the data classes. Because of how HNibernate works, it actually forces you into better practices. Now, once you (and hopefully the rest of you team) is really up to speed, thing can really crank out, and with minimal confusion. That is one of the signs of a good architecture, clear understanding of where things go.

Summer pays for Winter. The basic idea is to pay up front to reap rewards later. Yes it is a lot of work to implement an architecture around NHibernate, even if you are using a code generator, but there are rewards that make it worth it, if you follow through.

Expression is part of MSDN

I really need to keep better track of Soma's blog. He is in charge of all of Visual Studio.NET and MSDN after all.

Anyway, he just announced yesterday that Expression Web and Blend will be part of MSDN (as of yesterday for web, and Blend will be once it is released).

I see this as very good news, especially as that is what a lot of us have been asking for (yes, this did come up at the MVP Summit -- vocally!).