Bil Simser tagged me with this meme, thanks Bil.

As I tend to do with these things, I'll answer, but I'm not going to pass it on.

Apparently the idea is to list 5 things that'll make me a better developer over the next 6 months. The problem is, I'm not sure being a better developer is my primary focus just at the moment. But here's my list:

Keep my head above water

Microsoft has recently, and continues into the foreseeable future, to come out with new technology releases at a ridiculous pace. By "head above water" all I really mean is that I want, at least, to have a general clue about the purpose and real capabilities of all the stuff they are throwing at us. Not just the marketing hype, but what it really means. This, to me, has always been one of my primary strengths: the ability to grok most of the technologies available, and to figure out how they fit into some overarching architecture/worldview/philosophy.

But the current rate of change, and the amount of redundancy (ADO.NET, DataSets, LINQ, ADO.NET EF all solving the same problem? Come on!) makes this increasingly challenging. So over the next 6 months I'll be reading, talking to experts (and anyone else with something to offer) and experimenting in the hopes of keeping my head above water.

CSLA .NET

I used to learn new technologies by writing games - specifically MUDs and then low-end MMORPGs (well, I wrote and rewrote parts of one that never really came together). Someday I'd like to get back to doing that.

But in the meantime, I have CSLA .NET, and it has grown enough over the years that it affords me the opportunity to explore most of the key technologies I really want to learn. Having just released version 3.0, I got to dig into the plumbing behind WPF data binding, and explore the details around how WCF supports client/server (which it does well btw). Now my sights are turned toward two targets: .NET 3.5 and Silverlight.

The new language features, and of course lINQ itself, are key areas of focus for CSLA .NET 3.5. Fun stuff, no doubts there!

And if Silverlight 1.1 gets just a few more features (most notably data binding to objects), I believe I can create a CSLA Light that will provide a meaningful subset of CSLA .NET functionality within the Silverlight environment. If that pans out, it will be quite exciting

Magenic

Working for Magenic is great! I really enjoy the company and the people I work with. Over the next few months I'll be conciously spending more time and energy working internally with Magenic. As noted above, Microsoft's technology release schedule is grueling, and I want to make sure Magenic's consultants have the opportunity to stay on top of everything. This not only means doing some internal training, but more importantly working to build up a base of expertise and the infrastructure so other people can do some of that training (formally or informally).

It is (in my view) entirely unrealistic for one person to be an expert on everything that's going on. How can you credibly span .NET, Windows, Web, AJAX, SOA, Silverlight, SharePoint, Biztalk, SQL, Windows Server 2008 and everything else? You can't. But Magenic can, because we have a large enough pool of people that there's a decent level of expertise in all these technologies spread across the company. My challenge, then, is to coordinate that expertise such that the experts are in a position to share their knowledge with everyone else who needs it.

Of course Magenic has five offices across the country, and so there's the interesting sub-challenge of enabling the sharing of expertise across geographic distance. Actually it isn't the knowledge sharing that's such a big deal (we have great forums, etc), but it is the sharing if passion that is harder - and yet is at least as important.

Don't burn out

I've been feeling seriously burned out of late. That's not good. Part of it is due to the way travel grates on me more all the time, but most of it is that I haven't spent time doing truly exploratory things for a very long time now. CSLA has become quite consuming, and so my spare time goes into the framework, when I could be working on a .NET MUD engine or something really fun like that (I have these cool prototypes for truly dynamic world behavior that I'd love to pull together into something real).

It is also the case that I'm terrible about taking vacations. If I vacation at home, I work. That's the primary drawback with having a home office - work is always right there. But with Smartphones and laptops with wireless and/or cell modems the "office" can go almost anywhere, so even with a traditional office, escape is almost impossible.

Except... In August I'm spending a full week (nearly 10 days) in or near the Boundary Waters in far northern Minnesota. No meaningful cell coverage, no Starbucks or anywhere like it that would have wireless. Just untold miles and miles of wilderness, canoing, camping and fishing. Yea!

Remember the passion

Have you ever played that "what if" game? The one where you ask youself what job you'd do if you didn't do your current job?

I always draw a blank. If I had to do something else it would actually be work, rather than what I do now, which is to get paid for my hobby.

This, by the way, is what bothers me most about outsourcing, or even the software factory concept. It is true that economic needs shift over time, and steel workers needed to get new skills to find new jobs (as an example). I suppose it is possible that many of those steel workers had a burning passion for their job. That working with steel was their hobby as well as their job. But I doubt it. Most people I know view work as work: as a way to make money so they can do what they really want to do in their off hours. On the other hand, most developers I know view work as fun - and a way to make money while having fun.

Economists are often dismissive toward us, saying that if our jobs go offshore that we can just learn new skills and find different jobs. What they fail to understand is that we'd be doing far more than switching jobs: we'd be giving up an entire way of life. We'd be moving from a world of creative inspiration to a world of soul-crushing tedium. Yes, I realize I'm probably being very condenscending toward people with "normal" jobs, but this is how I see the world... (Then again, maybe economists do realize the deep love we have for what we do, and they envy us and so feel no remorse in talking about the destruction of our way of life?)

In any case, I love aspects of technology (especially building distributed and/or quasi-autonomous systems). And I love teaching about development. These things have been my passion since long before I officially started my career (when I was just a teenager, I was teaching elementary school kids how to use those new-fangled computers (Apples with no floating point support)). And I love writing - I really am what JMS describes as an "author" (one cursed to write because they can't not write). I can't imagine not doing most of the things I do today.

I think that's the key: remember the passion. Remember the fun. Yes, work hard, but more importantly code well, and perhaps above all: have fun!

CSLA .NET Version 3.0 is now available for download! Listen to the official announcement on .NET Rocks!

CSLA .NET 3.0 includes numerous enhancements and features of value to all CSLA .NET users, and of course version 3.0 adds support for Microsoft .NET 3.0 features like WCF and WPF.

You can use CSLA .NET 3.0 on either Microsoft .NET 2.0 or Microsoft .NET 3.0.

Features for everyone

CSLA .NET 3.0 includes enhancements useful to all CSLA .NET 2.1.4 users, including these highlights:

Validation rules

• PropertyFriendlyName – specify a friendly name to use when displaying broken rule text
• Format – specify a format mask to use when displaying broken rule numeric values
• StringMinLength – new validation rule method
• DecoratedRuleArgs – useful for code generation of AddBusinessRules() methods
• Fix bug with stopProcessing and rule priorities
• RegEx – rule method now supports options for dealing with null values

Authorization

• New CanExecuteMethod() functionality, similar to CanReadProperty() and CanWriteProperty()

Undo and Data binding

• If edit levels get out of sync an exception is thrown, making debugging of Windows Forms data binding much easier

Interfaces

• Cleaned up and rearranged interfaces to provide more consistency – making it easier to create UI frameworks on top of CSLA business layers

SmartDate

• Added TryParse() method
• Fix bug with CompareTo() method

SortedBindingList and FilteredBindingList

• Allow access to underlying source list

BusinessListBase

• Fix some bugs where ListChanged/CollectionChanged events were raised when they shouldn't have been. The result is that some data binding scenarios now work where they didn't, and in other cases performance is improved.

ProjectTracker\PTWin

• Reworked data binding code to address all known issues

See the change log for a complete list of changes.

Again, CSLA .NET 3.0 can be used without Microsoft .NET 3.0. If you want to build CSLA .NET 3.0 without installing the Microsoft .NET 3.0 runtime, you must define the NET20 symbol in project properties.

Microsoft .NET 3.0 Features

Of course the primary focus of CSLA .NET 3.0 is support for Microsoft .NET 3.0. Highlights include:

CSLA .NET

• WcfProxy – a data portal channel that uses WCF. You can transparently move from any existing data portal channel to WCF by using this new proxy.
• DataContract – support for using the WCF DataContract and DataMember attributes in your business classes
• WPF
  • CslaDataProvider – a data provider control that can create, fetch, save and cancel edits on a CSLA .NET business object. In some cases this can lead to code-less data entry forms!
  • Validator – a control that provides Windows Forms ErrorProvider-like behavior to WPF forms that are data bound to CSLA .NET objects.
  • Authorizer – a control that provides Windows Forms AuthorizeReadWrite-like behaviors to WPF forms that are data bound to CSLA .NET objects.
  • ObjectStatus – a control that exposes IsValid, IsSavable and other properties from a CSLA .NET business object so they can be used by XAML data binding.
  • IdentityConverter – a value converter that can be used to work around an issue with data binding and refreshing the UI.

The Csla solution is a Visual Studio 2005 solution. You can open and build the solution in Visual Studio 2005 if you have the Microsoft .NET 3.0 runtime installed on your workstation. Or you can use the NET20 symbol to allow compilation without the Microsoft .NET 3.0 runtime.

The Csla solution automatically upgrades when opened in Visual Studio 2008, and you can build the solution in Visual Studio 2008 if you are using that environment.

ProjectTracker\PTWpf

• Added new WPF UI with equivalent functionality to PTWin.

Note that this project is built using Visual Studio 2008 (Orcas) Beta 1.

ProjectTracker\PTWorkflow

• Added new Workflow UI to illustrate how a workflow can use CSLA .NET business objects

Note that this project is built using Visual Studio 2008 (Orcas) Beta 1.

ProjectTracker\PTWcfClient and PTWcfService

• Added a WCF service illustrating how to expose CSLA .NET objects through WCF/SOA
• Added a WCF client app illustrating how to call a WCF service

Note that these projects are built using Visual Studio 2008 (Orcas) Beta 1.

ProjectTracker\WcfHost

• Added a WCF host for the data portal

Note that this project is built using Visual Studio 2005 with the WCF extensions installed.

The ProjectTracker solution includes WcfHost, but does not include the other new projects. The reason for this is that the ProjectTracker solution is still a Visual Studio 2005 solution, while these other projects are built using Visual Studio 2008. The ProjectTracker solution upgrades automatically when opened in Visual Studio 2008, and in that environment you can add the remaining projects to the solution.

Migration

Migrating from version 2.1.4 to 3.0 should be relatively painless.

The only place you may encounter issues is that version 3.0 throws an exception if your edit levels get out of sync when using n-level undo. This may highlight pre-existing bugs in your UI code (especially in Windows Forms apps) that you should resolve. Look at the ProjectTracker\PTWin code for examples of the correct way to interact with Windows Forms data binding.

Migrating from 2.0.x to 3.0 has the same challenges as moving from 2.0 to 2.1. Version 2.1 introduced some significant, but important, changes to the handling of validation and authorization rules that can impact your business object code. See the CSLA .NET Version 2.1 Handbook for detailed information about version 2.1.

Migrating from 1.x to 3.0 will require some effort. There are many new features in 2.1 and 3.0 as compared to 1.x, and taking advantage of those features requires changes to your business objects and your UI code. You can look at the Expert C#/VB 2005 Business Objects books and the CSLA .NET Version 2.1 Handbook to get details around the scope of the changes.

Futures

I plan to write an ebook showing how to use the new features and enhancements in CSLA .NET 3.0. This ebook should be available in the third quarter of 2007 (probably September).

I’m working on CSLA .NET 3.5, based on Microsoft .NET 3.5 and focused on LINQ and various other new .NET features. Look for this in the first quarter of 2008.

I am also planning to update my Expert Business Objects books for Visual Studio 2008 and CSLA .NET version 3.5. This will probably come out in the second quarter of 2008.

You can see the roadmap here.

Just a quick reminder that the official 3 day CSLA .NET training roadshow continues through the summer. You can still attend in one of these cities:

• Orlando
• Chicago
• Washington, DC
• Dallas

The feedback from the classes so far has been excellent! I sat in on part of the class last week in Minneapolis, and I can see why. Miguel is a very good teacher, and his hands-on, continual lab style is a refreshing change from traditional powerpoint-heavy training.

CSLA .NET Version 3.0 Beta 2 is now available for download.

This is the final test release of version 3.0. Any changes between now and release will be bug fixes.

If you plan to upgrade please consider helping yourself and the community at large by downloading this version and testing it before July 5. Let me know about any issues through the forum.

CSLA .NET 3.0 provides support for Microsoft .NET 2.0 and 3.0.

If you want to build CSLA .NET 3.0 without .NET 3.0, you must define the NET20 symbol in the project properties.

CSLA .NET 3.0 includes enhancements useful to all 2.1.4 users, including these highlights:

Validation rules

·         PropertyFriendlyName – specify a friendly name to use when displaying broken rule text

·         Format – specify a format mask to use when displaying broken rule numeric values

·         StringMinLength – new validation rule method

·         DecoratedRuleArgs – useful for code generation of AddBusinessRules() methods

·         Fix bug with stopProcessing and rule priorities

·         RegEx – rule method now supports options for dealing with null values

Authorization

·         New CanExecuteMethod() functionality, similar to CanReadProperty() and CanWriteProperty()

Undo and Data binding

·         If edit levels get out of sync an exception is thrown, making debugging of Windows Forms data binding much easier

Interfaces

·         Cleaned up and rearranged interfaces to provide more consistency – making it easier to create UI frameworks on top of CSLA business layers

SmartDate

·         Added TryParse() method

·         Fix bug with CompareTo() method

SortedBindingList and FilteredBindingList

·         Allow access to underlying source list

ProjectTracker\PTWin

·         Reworked data binding code to address all known issues

See the change log for a complete list of changes.

Of course the primary focus of CSLA .NET 3.0 is support for Microsoft .NET 3.0. Highlights include:

·         WcfProxy – a data portal channel that uses WCF. You can transparently move from any existing data portal channel to WCF by using this new proxy.

·         DataContract – support for using the WCF DataContract and DataMember attributes in your business classes

·         WPF

o   CslaDataProvider – a data provider control that can create, fetch, save and cancel edits on a CSLA .NET business object. In some cases this can lead to code-less data entry forms!

o   Validator – a control that provides Windows Forms ErrorProvider-like behavior to WPF forms that are data bound to CSLA .NET objects.

o   Authorizer – a control that provides Windows Forms AuthorizeReadWrite-like behaviors to WPF forms that are data bound to CSLA .NET objects.

o   ObjectStatus – a control that exposes IsValid, IsSavable and other properties from a CSLA .NET business object so they can be used by XAML data binding.

o   IdentityConverter – a value converter that can be used to work around an issue with data binding and refreshing the UI.

ProjectTracker\PTWpf

·         Added new WPF UI with equivalent functionality to PTWin.

ProjectTracker\PTWorkflow

·         Added new Workflow UI to illustrate how a workflow can use CSLA .NET business objects

ProjectTracker\PTWcfClient and PTWcfService

·         Added a WCF service illustrating how to expose CSLA .NET objects through WCF/SOA

·         Added a WCF client app illustrating how to call a WCF service

ProjectTracker\WcfHost

·         Added a WCF host for the data portal

A CSLA .NET user, Aaron Nottestad, has been helping test 3.0 and ran into some issues when using the new WPF CslaDataProvider with editable objects. Thanks Aaron!

As a result, I had to do some work with CslaDataProvider, so it can manage the object’s entire lifetime from create/fetch through to save/cancel. If it can’t manage the lifetime, especially the save, then it can’t get the new object that comes back as a result of save. And if it doesn’t get that new object, then neither does data binding, so the UI controls end up editing an old instance of the object.

So the CslaDataProvider now has Save() and Cancel() methods that you can call to trigger saving or canceling of the business object. Also, as the object is created/fetched CslaDataProvider automatically calls BeginEdit() on the object.

This behavior is all optional, and is controlled by the ManageObjectLifetime property of the CslaDataProvider control. So if you want this behavior, you have to set that property to True. If you leave it at False (the default), then you must manage everything through code – though honestly you can’t manage editable objects through code while using CslaDataProvider. So maybe I should make the default be True? Hmm.

Anyway, this was easy enough to do and worked great. The resulting forms had exactly 4 lines of code – 2 to call Save() and 2 to call Cancel(). It occurred to me that there must be a way to avoid writing those 4 lines of boring code, and Aaron put me onto the RoutedCommand concept in XAML.

A RoutedCommand allows a control like a button or menu item to invoke a method on another control – purely through XAML. There are many examples out there about how this works to create standard Copy/Paste menu items that run against the current TextBox control, and that sort of thing. But none that I found which routed a command to a data provider control.

The reason turns out to be that the target of a command must be a UIElement, and data providers don’t inherit from that base class. Oops…

I thought I was stuck, because I really do want to route the command to CslaDataProvider in this case. However, I figured out a solution.

CslaDataProvider now has a read-only CommandManager property. This property exposes a “command manager” object which does inherit from UIElement and which does handle the Save and Undo routed commands. When it is created by CslaDataProvider, it is given a reference to the CslaDataProvider control, so it simply delegates all Save commands to the CslaDataProvider.Save() method and all Undo commands to CslaDataProvider.Cancel().

With that done, you can route a command from a button or menu item (or any other valid command source) to this CommandManager object, which effectively means you’ve routed the command to the CslaDataProvider control.

The CslaDataProvider gets declared like this:

    <csla:CslaDataProvider x:Key="ChildList"

                           ObjectType="{x:Type this:ChildList}"

                           FactoryMethod="GetList"

                           IsAsynchronous="False"

                           ManageObjectLifetime="True">

    </csla:CslaDataProvider>

Then the button controls get declared like this:

            <Button

              Command="ApplicationCommands.Save"

              CommandTarget="{Binding Source={StaticResource ChildList},

                              Path=CommandManager, BindsDirectlyToSource=True}"

              HorizontalAlignment="Left" IsDefault="True">Save</Button>

            <Button

              Command="ApplicationCommands.Undo"

              CommandTarget="{Binding Source={StaticResource ChildList},

                              Path=CommandManager, BindsDirectlyToSource=True}"

              HorizontalAlignment="Left" IsCancel="True">Cancel</Button>

The result is very cool: a form that can edit an object without the need to write any C# or VB code at all. Coupled with the CSLA .NET ValidationPanel to display validation results, you can create a highly interactive data edit form purely with XAML – and of course a CSLA .NET style business object doing all the work behind the scenes.

These new capabilities will appear in CSLA .NET 3.0 Beta 2 - hopefully later this week.

I’ve been spending some quality time with WPF and Visual Studio 2008 Beta 1 (Orcas) over the past few months. A couple observations I’ve made:

Observation ichi:

Putting code in a Page/Window constructor is bad. Yes, I know it is the “C# way”, but it is bad. The “VB way” of putting code in the Loaded event handler is better.

Why?

Because any exceptions thrown in the constructor prevent the page/window from loading at all, and you have to catch those exceptions in the code that is creating the page/window. In many navigation scenarios you can’t catch them, so the user gets an ugly WPF exception dialog.

However, if you do all your init work in the Loaded event handler, the page/window instance already exists. Navigation has already happened, so the “calling code” is no longer responsible for your page/window going haywire. Instead, you can actually handle the exception and show a nice dialog, explaining to the user what happened, and you can (if desired) navigate somewhere else or whatever.

Observation ni:

Handing control events with += or AddHandler is superior to using WithEvents/Handles. Yes, I am a strong advocate of WithEvents/Handles, and it is one of the major missing features in C#, but for WPF it turns out to be a negative.

Why?

Because the Handles clause links the name of the control to the code behind. The AddHandler or += approach, while less attractive in many ways, only couples the event name to the code behind.

In other words, when using Handles you get code like:

Private Sub Button1_Click(ByVal sender As Object, ByVal e As EventArgs) _
  Handles Button1.Click

While the AddHandler approach results in this code:

Private Sub SaveData(ByVal sender As Object, ByVal e As EventArgs)

The value of the second approach is that any control can route an event to SaveData(). It doesn’t have to be a button, much less Button1. It actually doesn’t even have to be a Click event. It could be almost any event.

The result is that the Presentation (XAML) is less coupled to the UI (VB/C# code) this way than when using Handles.

Unfortunately the Handles approach is more explicit and thus more readable (which is why C# should really get the Handles feature), so we’re left trading readability in order to gain loose coupling…

I posted previously about an issue where the WCF NetDataContractSerializer was unable to serialize a SecurityException object. Microsoft provided some insight.

It turns out that the constructor of the SerializationException object doesn't set the Action property to anything valid. Before you can serialize a SerializationException with NDCS you must explicitly set the Action property to a valid SecurityAction.

This does mean that NDCS is not compatible with the BinaryFormatter in this case, but at least there's a workaround/solution.

I've now updated CSLA .NET 3.0 to explicitly set the Action property any time a SecurityException is thrown, thus allowing the WCF data portal channel to return valid details about the nature of any exception.

The WCF NetDataContractSerializer is an almost, but not quite perfect, replacement for the BinaryFormatter.

The NDCS is very important, because without it WCF could never be viewed as a logical upgrade path for either Remoting or Enterprise Services users. Both Remoting and Enterprise Services use the BinaryFormatter to serialize objects and data for movement across AppDomain, process or network boundaries.

Very clearly, since WCF is the upgrade path for these core technologies, it had to include a serialization technology that was functionally equivalent to the BinaryFormatter, and that is the NDCS. The NDCS is very cool, because it honors both the Serializable model and the DataContract model, and even allows you to mix them within a single object graph.

Unfortunately I have run into a serious issue, where the NDCS is not able to serialize the System.Security.SecurityException type, while the BinaryFormatter has no issue with it.

The issue shows up in CSLA in the data portal, because it is quite possible for the server to throw a SecurityException. You'd like to get that detail back on the client so you can tell the user why the server call failed, but instead you get a "connection unexpectedly closed" exception instead. The reason is that WCF itself blew up when trying to serialize the SecurityException to return it to the client. So rather than getting any meaningful result, the client gets this vague and nearly useless exception instead.

By the way, if you want to see the failure, just run this code:

    Dim buffer As New System.IO.MemoryStream
    Dim formatter As New System.Runtime.Serialization.NetDataContractSerializer
    Dim ex As New System.Security.SecurityException("a test")
    formatter.Serialize(buffer, ex)

And if you want to see it not fail run this code:

    Dim buffer As New System.IO.MemoryStream
    Dim formatter As New System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
    Dim ex As New System.Security.SecurityException("a test")
    formatter.Serialize(buffer, ex)

I've been doing a lot of work with the NDCS over the past several months. And this is the first time I've encountered a single case where NDCS didn't mirror the behavior of the BinaryFormatter - which is why I do think this is a WCF bug. Now just to get it acknowledged by someone at Microsoft so it can hopefully get fixed in the future...

The immediate issue I face is that I'm not entirely sure how to resolve this issue in the data portal. One (somewhat ugly) solution is to catch all exceptions (which I actually do anyway), and then scan the object graph that is about to be returned to the client to see if there's a SecurityException in the graph. If so perhaps I could manually invoke the BinaryFormatter and just return a byte array. The problem with that is in the case where the object graph is a mix of Serializable and DataContract objects - in which case the BinaryFormatter won't work because it doesn't understand DataContract...

In the end I may just have to leave it be, and people will need to be aware that they can never throw a SecurityException from the server...

A fellow Magenicon has also blogged in response to Fowler's comments about the .NET world.

Strangeloop is one of the coolest products I've seen (not as cool as Surface, but that's hard to top ).

This product is an ASP.NET-aware device that does intelligent caching for web sites. It can do things that seem virtually impossible - it is that cool! Here's Richard Campbell's blog entry with more background.

If you have the need for a nearly transparent boost in performance for your ASP.NET web site, Strangeloop is something you should look at!

Martin Fowler’s recent blog post about Ruby and Microsoft has some good points. But he, like many outside the Microsoft space, make a faulty assumption about why there seems to be a lack of excitement in the Microsoft space.

I don’t believe the lack of excitement is because we’re all bored. Conversely, the lack of excitement is because we’re overwhelmed. Who has time to be excited? Not only do we all have real work to do with the technologies we have today, but on our doorstep is a mounting pile of new and potentially better technologies.

There’s certainly some truth to the idea that alpha geeks (or uber-geeks) live for the thrill of technology. But even most uber-geeks are finding the incredible pace of Microsoft product releases to be overwhelming.

We’re not just talking about pure dev tools, and perhaps that’s the problem. We’re talking about Biztalk Server, SharePoint Server, Microsoft Office itself and a whole bunch of other programmable server products. Each of these can be thought of as massive frameworks that a developer can tap into.

That’s on top of the peripheral dev tools like VSTS and TFS and all the various versions of Visual Studio Developer/Test/whatever. (Fowler is right on this one – few if any organizations divide their people into such rigid roles and Microsoft did a bad thing by defining their SKUs the way they did.)

Then there are the major platform-changers like AJAX and Silverlight. And the related tooling like Expression Blend and the rest of the Expression Suite. Like it or not, developers are almost certainly going to have to learn not only these technologies, but these not-really-designed-for-the-developer type tools. You can’t build a meaningful WPF or Silverlight app without using Blend. Sorry, but there it is.

If that isn’t enough to get a person scared, then there are the actual dev tools. A new version of Visual Studio (code-named Orcas) is mere months away, just as many people are moving to VS 2005. A new version of .NET (3.0) is already out, and yet most people have barely looked it. And along with VS Orcas will come .NET 3.5, which is in many ways a bigger change than 3.0!!

For application architects the challenges here are tremendous. How to exploit the productivity gains offered by all these new and upcoming technologies, and yet mitigate the risks they entail. Is it cheaper, for a given project, to use Windows Workflow or Biztalk Server? How much time could be saved by switching an application’s file store over to SharePoint Server, but what’s the cost in terms of learning that new API/framework?

Given the broad lack of real-world experience with these new technologies, there’s no realistic way to know what the cost/benefit will be for any given technology. Even those of us “in the know” are barely aware of the true value propositions and risks they pose.

At the same time, it is a faulty assumption to think that we’re not excited. Like a great many people in the Microsoft space, I am very excited about the upcoming language features in C# and VB! There’s absolutely no doubt in my mind that LINQ will literally transform the way we write code.

And then there’s the Dynamic Language Runtime (DLR) coming in Silverlight, along with VBx and other dynamic languages like Ruby and Python. Take all the incredible coolness of VB 9 with LINQ and the related language enhancements, then add a liberal coating of fantastic dynamic language features (beyond the ones VB has had since day 1) and who wouldn’t be excited!?!

But at the same time, you’ll have to forgive the vast majority of developers if they see all this as a double-edged sword. Any major change comes with a price: a period of weeks or months of reduced productivity. For an alpha/uber geek this might be weeks, but it is still a productivity killer.

I don’t know what it is like outside the Microsoft world, but in our world we are busy, busy, busy!! A few weeks or months of reduced productivity to become proficient at WPF, WCF, WF, LINQ and all the other new language features is a hard pill to swallow. From a business planning perspective, the unknowns involved in such huge changes is very risky, and so is also a hard pill to swallow.

Yes, every single one of these technologies is totally awesome! Having spent a lot of time with WPF over the past few weeks, I can say that it is a serious productivity killer, and yet I haven’t had so much fun building a UI in years. Given another few weeks I imagine I’ll be building WPF UI’s just as fast as I can with Windows Forms, but those UI’s will be far more flexible and will require substantially less code to write.

Personally, I want to build my WPF app and then run it on a Microsoft Surface platform. Welcome to the world of Star Trek!!

The CSLA .NET community has been very fortunate, in that people from all over the world have contributed their time and effort to build CSLA resource files for many languages. In CSLA 3.0 I added some new resource strings, and so there is a need to add some new translations to each language's resx file.

If you are willing to update (or create a new) resx file for your language that is very kind. You will gain the benefit of having the proper translations, as will your fellow countrymen.

You can also get the resx files from here:

http://www.lhotka.net/cslacvs/viewvc.cgi/trunk/cslavb/Csla/My%20Project/

The English file is called Resources.resx, and it is the master list.

For most language files, this view should give the differences since version 2.0:

http://www.lhotka.net/cslacvs/viewvc.cgi/trunk/cslavb/Csla/My%20Project/Resources.resx?r1=1282&r2=1465

Knut Vonheim kindly put together a spreadsheet listing the new, obsolete and continued values for the resource file. It may be helpful for anyone doing more translations. You can get it from:

http://www.lhotka.net/files/csla30/CSLAValues2.xvs3.0.xls

Not all language files have been kept in sync at all times, so you may want to check your specific language to make sure it is completely correct and complete.

Once you have updated your language's resx file, please EMAIL THE RESX to rocky (at) lhotka (dot) net.

For reference purposes, I have created a wiki page with the list of languages for CSLA 2.0 and 3.0

http://www.lhotka.net/wiki/default.aspx/LhotkaWiki/GlobalLanguages.html

I'll keep updating this location as I get translations from people and add them to CSLA 3.0. Right now, the following languages are complete:

Thank you for helping the CSLA community!