In a nutshell, he acknowledges that to use the BCL and write .NET classes in .NET you need language features that C++ doesn’t have.  So you need something like C++/CLI.

But he also makes it clear that you don’t want code that uses C++/CLI extensions scattered throughout your application.

Well, maybe you do.  These features are there for a reason – because they make development easier – but using them ties your application to the CLR.

It’s possible to write a managed application in C++ and still maintain separation between the portable C++ and the .NET specific C++.

And if you’re going to do that, my suggestion would be to write the managed portion in C#. 

If you know C++ you already mostly know C#, and writing the .NET specific portion of your app in C# and calling it from the C++ code makes the separation clear.

I miss working with the .NET Framework.

IList results = _session.Find(“from MyAssembly.MyClass as MyClass where MyClass.Foo = ?”,
    tagText, TypeFactory.GetStringType(64));

You can pass in arrays of objects and types for the last two parameters if you have more than one parameter in your HQL.

I must say I’m impressed.  The folks who ported Hibernate from Java to .NET did a good job of making it feel like a first class .NET library, and not just a port.  This introduction to NHibernate by Jason Gehtland is excellent (and here’s part two), and with it I had my first classes mapped into database tables in just a few minutes.

I haven’t taken the item off my todo list because there’s still so much to learn about it, but I can see it’s going to be a huge time saver.

Part of creating a user interface is separating the work from the UI thread, so that the UI can remain responsive and report progress while a long operation is running.  This isn’t rocket science, but it is a bit of tedious development that every Windows Forms developer has had to learn how to do.  Not anymore.

Let’s say you want to count to a billion, on a background thread.  Here’s how you’d do it:

1. Drop the BackgroundWorker object from the Toolbox onto your form.
2. Add a handler for the DoWork event (double-click on DoWork in the Properties for your BackgroundWorker object)
3. Call or write your code in the DoWork handler.
4. When you want to run your asynchronous operation, call the backgroundWorker.RunWorkerAsync() method.

That’s it – no messing with threading or locking, it’s all handled by the BackgroundWorker object. 

The only thing that would have made it easier to implement background operations would have been supplying a standard progress dialog – you’ll have to implement that yourself.  Reporting progress is also handled through the BackgroundWorker object – in your worker thread you call ReportProgress, and on the main thread handle the ProgressChanged event.

A problem I ran into is that the 3 new sites share the same domain name, and the same directory (and thus the same web.config file) but they’re actually 3 different ASP.NET application domains.  This is okay – I sniff out in the first Request_Start what the requesting directory is (ie, “/brantford”) and from that look up the configuration for that specific site in the database. 

The cookie path that Forms Authentication uses, however, is specified in the web.config file, and isn’t modifiable once set (FormsAuthentication.CookieDomain is a read-only property).

I wanted a different cookie path for each virtual site, so I had to override this.  There are two places where this involved changes.

The first is when the user logs in:

protected void Login1_LoggedIn(object sender, EventArgs e)

{

    HttpCookie cookie = FormsAuthentication.GetAuthCookie(Login1.UserName, 

        Login1.RememberMeSet);

    string cookiePath = Request.Url.AbsolutePath;

    int slashIdx = cookiePath.IndexOf(“/”, 1);

    if (slashIdx != -1)

    {

        cookiePath = cookiePath.Substring(0, slashIdx);

        cookie.Path = cookiePath;

        Response.Cookies.Set(cookie);

    }

}

This code finds the cookie that Forms Authentication created when the user logged in, and replaces the cookie path with one calculated for this site.

The second change is when the user logs out:

protected void loginStatus_LoggedOut(object sender, EventArgs e)

{

    string cookiePath = Request.Url.AbsolutePath;

    int slashIdx = cookiePath.IndexOf(“/”, 1);

    if (slashIdx != -1)

    {

        cookiePath = cookiePath.Substring(0, slashIdx);

        HttpCookie cookie = Request.Cookies[FormsAuthentication.FormsCookieName];

        cookie.Path = cookiePath;

        cookie.Expires = DateTime.Now.AddDays(-1);

        Response.Cookies.Add(cookie);

    }

}

This ensures that the correct cookie is set to expire when the user logs out.

It means you tried to insert a row with a null value in a column that doesn’t allow nulls.  Bad message.