If you're using LINQ to SQL with SQLCE and use the DataContext.CreateDatabase() method, you may encounter this error.  If you used the LINQ to SQL class designer to generate the classes from a different database provider (such as SQL Server 2005 or SQL Server Express), the table source names may be prefixed with "dbo."

Just remove the prefix, and CreateDatabase() will succeed.

I'm posting this for future reference.  If you invoke a PageFunction and add an event handler to the PageFunction's Return event, the event handler must be an instance method of the calling page.  No other method will do.  If the event handler doesn't meet this criteria, you'll see the FatalExecutionEngineError thrown when you return from the PageFunction.  Sorry, no separation of concerns allowed.

More details in this forum thread: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1975763&SiteID=1.

We recently upgraded to VS 2008 RTM at work, and shortly after discovered that a new build of our ClickOnce-deployed WinForms application failed to install correctly!  During the download process, a message box would display, and the log details revealed an InvalidDeploymentException (RefDefValidation) in System.Deployment.Application.DownloadManager.ProcessDownloadedFile().

Let me just say that days of fruitless investigation followed.

I'm happy to report that I finally did find the solution (completely by accident).  A new option has been added to Visual Studio, allowing you to automatically create and embed a manifest in your application.  This manifest allows you to provide proper application behavior when running under UAC in Vista.  Here's the option, on the Application property page of the Visual Studio project:

When you upgrade a WinForms project from VS2005 to VS2008, this option is automatically set for you.  If you had identified the application as a ClickOnce application in VS 2005, the resulting deployment from a VS2008 build works correctly.

Real-world ClickOnce

If you're like me, you're developing in a professional environment where you can't just click the Publish Now button and send an app from your development box into production.  Is it just me, or does everyone think that's insane?  Do you think we might want to QA those phasers first, Captain?

We have a relatively complex build that builds our ClickOnce manifests based on the target environment (Dev, QA, or Production) so that we can test ClickOnce updates from previous versions before going to production.  Also, since we've had our ClickOnce app deployed for more than one year, we had to overcome the certificate renewal problem, which requires a special signing process using both the expired and the current signing certificate.  Needless to say, neither of these can be set up in Visual Studio.  What we ended up with is a build where the ClickOnce options are not set in the Visual Studio project, but externally in an MSBuild project file, using many of the built-in targets that VS uses.

Migrating from VS2005

When the project was converted to VS2008, it was upgraded by the wizard as if it wasn't a ClickOnce project.  This means that the manifest setting was set incorrectly.

Here's what the Visual Studio documentation has to say about the manifest setting:

Phil Haack posed a question today about dependency injection frameworks:

Normally, I would just specify a type to instantiate as another PluginFamily entry. But what I really want to happen in this case is for StructureMap to call a method or delegate and use the value returned as the constructor argument.

...

Does anyone know if something like this is possible with any of the Dependency Injection frameworks out there? Whether via code or configuration?

I don't have much experience with the big three DI frameworks Castle Windsor, Spring.NET and StructureMap, but what I've seen suggests that these are strongly configuration based.

That means that I can specify a concrete type name in a configuration file that the framework will use to instantiate a particular interface type.  For example, in Spring.NET, you might specify the concrete type like this:

            <objects xmlns="http://www.springframework.net">
          

                <object
          

                    name="TheClassIWant"
          

                    type="MyNamespace.MyConcreteClass,
MyAssembly"
          

                </object>
          

            </objects>
          

Then in your code, you can ask Spring to create an instance of MyConcreteClass like so:

IApplicationContext ctx = ContextRegistry.GetContext();

MyConcreteClass instance = (MyConcreteClass)ctx.GetObject("TheClassIWant");

That's all well and good.  In Phil's case, though, he wants to specify a way to create an instance of MyConcreteClass in code rather than configuration.  Let's take that requirement more generally and assert that we know what concrete classes we want to instantiate in our application, but just don't want the whole application to know.  Maybe I need an instance of ISomeInterface in some part of my code, but that code doesn't know how to get an ISomeInterface.  What I want is some global mechanism to define how to get an instance of some type, and then a way to get the type.  Now, how do we do that in code?

Simple Service Locator

I had some spare time while at DevConnections, and decided to create just that - a code-based service locator.  The basic idea is that we'll have a ServiceLocator class that maps interface types to concrete types.

At some point in your code, you register a concrete type for an interface:

            ServiceLocator locator
= newServiceLocator();

locator.Register<ITest>(typeof(Test));

This means that when we ask for instance of the interface ITest, ServiceLocator will create and return an instance of Test (the implication of course is that Test implements ITest).  Here's how we ask for an ITest:

            ITest instance = locator.Get<ITest>();

If you expose a singleton instance of ServiceLocator in your application, you can register your types at startup, and then use the locator to instantiate the concrete types from anywhere in the code.

What about parameterized constructors?

Default constructors are the trivial case.  How do we handle creation of concrete types that require constructor parameters?  We have two cases:

1. The parameter is an interface that we want ServiceLocator to instantiate
2. The parameter is a value that we want to provide explicitly.

Here's how we handle the first case:

locator.Register<ICat>(typeof(Cat), typeof(IOwner));

locator.Register<IOwner>(typeof(Owner));

            ICat instance = locator.Get<ICat>();

Here we're saying that if we want an ICat, we need to create a Cat with the constructor Cat(IOwner).  By registering IOwner to create an Owner, ServiceLocator is able to create a Cat by first instantiating an Owner and passing that value to the Cat constructor.

In the second case, we have some value that ServiceLocator doesn't know how to create.  Let's suppose the Cat constructor takes an IOwner and a string:

locator.Register<IOwner>(typeof(Owner));

locator.Register<ICat>(typeof(Cat), newTypeParameter(typeof(IOwner)), newTypeParameter(typeof(string), "Kitty"));

            ICat cat = locator.Get<ICat>();

In this case, ServiceLocator will call the constructor Cat(IOwner, string) with an IOwner it creates, and the string "Kitty".

And Singletons?

Sometimes we always want the same instance of an object:

            Cat kitty = newCat();

locator.Register<ICat>(kitty);

            ICat cat = locator.Get<ICat>();

Here we always return the instance kitty when an ICat is requested.  We all know how hard it is to work with a large number of cats.

Le Delegate

Yes, there is a Santa Claus.  I might have some code that is responsible for creating an object.  Perhaps it's responsible for managing a pool of objects, or just has some complexity that would be difficult to express in configuration.  I want to register a delegate that will provide the instance.

locator.Register<ICat>(delegate()
{ return kitty.IsSleeping ? buffy : kitty; });

            ICat cat = locator.Get<ICat>();

Here I provided an anonymous method in the Register() call, but I could just as easily register some other class method.

So there you have it - a configuration-free service locator with quite a bit of flexibility in object creation.

You can download the source for my ServiceLocator here.  The project was built in Visual Studio 2008.

Should I Use it?

If it works for you!  It's free of course.  However, I conjured this up in an hour or two, so it's not likely that ServiceLocator offers anywhere near the capabilities of a full-fledged dependency injection framework.  I'd encourage you to look closely at Castle Windsor, Spring.NET and StructureMap.  I'm sure that there are other great frameworks too.

I'd be grateful for any feedback as always.

Today's entry is dedicated to environmental appreciation.

In the early ages of man, the earth was wild, cold, and full of danger.  We have waged war on the unruly forces of nature for thousands of years.  Compared to our savage upbringings, we live now in an unimaginable paradise of warmth, comfort and plenty.  A few isolated families scattered over a wide dark land now find themselves amongst a crowd of constant companionship and entertainments.  So far we have come.

We have laid low mountains, dammed rivers, harnessed the atom.  Nothing can withstand us.  Yet with our great advances, we've lost many of the empty spaces in our world.  Most is paved, groomed and domesticated.  So much so that few of us could live without civilization.  We could not feed or shelter ourselves, or find our way through a wild land.  Our very souls are tamed by the comfort and convenience of modern life.

That is why I value what wilderness and open spaces we have left.  Walking amongst the mountains and woods of nature is a breath-taking experience of the natural beauty and majesty of creation, so absent from our everyday modern reality.

It's an opportunity to recapture the simple joy of challenging ourselves against primal forces.  Hiking long distances, climbing, finding food, making fire and shelter.  Having to rely on your own problem-solving abilities and carry your own water.  Can we claim to be human without doing these things?

Every year I take my family on a pilgrimage to the woods.  Every time there are aches and pains, cold mornings, and often rain.  And yet it's always the best week of the year.

In the struggle against nature, we have defined ourselves.  Now that we are victorious, we have the luxury to choose how we relate to nature.  I'm grateful that we have chosen to preserve at least some of it, and hopeful that we will be good stewards to what is left of this crucible of humanity.  We have enough pavement.

Note: You can download the complete implementation here.

I just posted a new version of ObjectListView that fixes a couple of bugs and adds some minor usability enhancements.

I've been using ObjectListView more in different projects, and I'm feeling the pain points.  Foremost, a complete IBindingListView implementation means that interaction with Windows Forms controls works smoothly, but that doesn't mean it's easy for the developer to use.

PropertyDescriptors Everywhere

I don't like working with PropertyDescriptors as method parameters.  In order to find a list item via IBindingList,.Find(), you need to get the descriptors for the list item type from TypeDescriptor, and then look up the correct one by the property name.  Awkward.  Moreover, all that Find() gives you is the first item found for which one property equals a specified value.  I've added two more useful Find() overloads.  One takes a string expression that can be an arbitrarily complex set of property comparisons (using the same syntax as the Filter property).  The other allows you to specify a Predicate delegate to provide a comparison in code.  Given these, the original Find() required for IBindingList seems unlikely to be used, so I changed it to an explicit interface implementation.  This has the effect of hiding the overload from the publicly exposed class methods, but still making it available to consumers of IBindingList.

Select

One of the useful methods of DataTable is Select(), which returns the set of DataRows in the table that match a given criteria.  Now clearly, you could iterate over the items in the view yourself and evaluate each, but having this built in to ObjectListView is very convenient.  As with Find(), I added two versions, one that takes a string expression, and the other that takes a delegate.  The return value of Select is a list of items that match the criteria.

Property Paths

Something I've had in mind for a while is being able to filter on list items based on the values of properties of properties.  You could use FilterPredicate to specify such a filter with a delegate, but it would be even more convenient to use an expression like "Customer.AccountRep.Department = 2".  The new version 1.0.0.11 supports this kind of property path in the Filter property, Find() and Select().  Currently, changing the value of one of the sub-properties specified in a Filter property path will not cause the view to be updated.  I need to do more work before I have an efficient implementation of the notification logic.

Item Deletion Events

ObjectListView has always provided the ListChanged event, which specifies an action type (ListChangedType).  One of the actions reported is Deleted, indicating that a list item has been removed.  Unfortunately, only the index of the item deleted is available at the time the event is raised; the item has already been removed.  I've added the RemovingItem event, which is raised just before an item is removed from the list.  This event is only raised when an item is removed through a method of ObjectListView (for example, view.Remove() or view.RemoveAt()).  If an item is removed through a method of the underlying list, the deletion is reported to ObjectListView after the fact, so RemovingItem cannot be raised.

Bugs

As always, a few bugs are fixed, and some minor clean-up done.  See the change log for details.

What's Cooking?

As I mentioned, there's work yet to be done in keeping the view up to date as sub-properties specified in the Filter expression change.  I'm also working on dynamic properties that can be added to the view.  These would be analogous to the expression columns supported by DataTable.

I'm also excited to be presenting ObjectListView at the Portland Code Camp in two weeks!  I think it will be hard to explain it all in an hour.  I'll just have to talk really, really fast.

I just got a new notebook PC with Vista pre-installed.  After removing all the OEM applications and finally re-paving to remove a wasted (er, "recovery") partition, I'm installing all my development tools.

One tool I've really come to appreciate is the AnkhSVN plugin for Visual Studio 2005.  Ankh integrates the Subversion (SVN) source code control system with VS.  I've used Subversion at work for the last two years, and I have to say I'm a fan.  Even so, my prior history was with Visual SourceSafe, and I've kept that on as my source control system at home.  No more - I've decided to take the plunge and move to SVN everywhere.

Unfortunately, after installing AnkhSVN and restarting Visual Studio, I received a not-too-helpful error message from Visual Studio: "The Add-in AnkhSVN failed to load or caused an exception, etc etc...Class not registered  Error number: 80040154".

Well.

Googling turned up a thread between Jon Skeet and Arild Fines discussing the problem.  Jon was able to successfully install Ankh after uninstalling it, adding the following registry keys, and then reinstalling AnkhSVN:

[HKEY_CLASSES_ROOT\AnkhUserControlHost.Ankh] 
[HKEY_CLASSES_ROOT\AnkhUserControlHost.Ankh\CLSID] 
[HKEY_CLASSES_ROOT\AnkhUserControlHost.AnkhUserControlHostCtl] 
[HKEY_CLASSES_ROOT\AnkhUserControlHost.AnkhUserControlHostCtl\CLSID] 
[HKEY_CLASSES_ROOT\AnkhUserControlHost.AnkhUserControlHostCtl.1\CLSID] 
[HKEY_CLASSES_ROOT\AnkhUserControlHost.AnkhUserControlHostCtl.1\CLSID] 

I tried this and it didn't work at all.  After trying a number of over things (also starting with "reg"), I re-tried the above steps, but chose to install for ALL USERS instead of just me.  It worked!  Whew.

If you're still using Visual SourceSafe, you might try giving Subversion and AnkhSVN a shot.  I've used sccs, rcs, PVCS, VSS, CVS, and Subversion, and the Subversion tool set is the clear winner in my opinion.  It's free, too!

Update (2/13/08):  The current development pre-releases of AnkhSVN support Vista and VS2008 with no registry changes.  I've been using version 1.0.3.2800 for a few weeks now and it's working great.  You can get the latest here.

Note: You can download the complete implementation here.

For those of you just tuning in, ObjectListView is my answer to the .NET need for a DataView-like construct for ordinary objects.  With ObjectListView, you can have a sorted and filtered view of any IList or IList<T>.  You can bind this view to controls like the DataGridView.

This new version adds a debugger visualizer and includes a few other small enhancements and bug fixes.

Bug Fixes

Ecki found a bug in the Master/Details demo where I was doing an invalid cast in the New button click handler.  I also found that .NET 1.1 style property change events weren't wired properly for items already in the list at the time an ObjectListView was constructed.  Those two are fixed.

Boris reported that changing a list item property while iterating over ObjectListView with a foreach loop would cause an InvalidOperationException to be thrown.  Indeed!  This is by design; any change to a .NET collection must invalidate all enumerators of the collection.   ObjectListView is really a view over a collection, though, and not a collection itself.  This view presents the appearance of a collection.  This virtual collection does change when items are added, removed, or replaced in the underlying collection.  When the value of a list item property changes, however, the virtual collection only changes in certain circumstances.  Fortunately, these circumstances are well-understood:  if the property is not included in either the ObjectListView sort or filter, the virtual collection does not change.  In this case, there is no need to invalidate any enumeration in progress.  In the updated version, ObjectListView allows enumeration to continue following a list item property change if the property does not belong to the sort or the filter criteria.

Small Changes

I added a ToArray() method, as I find it irritating to have to declare an array and copy into it with CopyTo() in two steps.  By request, OnListChanged(), OnSorted() and OnAddingNew() are now protected virtual, for extensibility.  These methods follow the usual convention of event-raising methods in .NET.  If you override one of them, be sure to call the base version so that the event will in fact be raised.

License

Since more than a few have asked, I've added the license terms to the Readme.txt file of the download.  ObjectListView is free - no strings attached.

The Visualizer

This is the big cool addition in my estimation.  If you're debugging a program that uses ObjectListView, you can see a nice dialog that shows you the current state of the ObjectListView and it's underlying list.  At a breakpoint, move the mouse over the variable that is the ObjectListView, and click the little magnifying glass.  You'll see something like this:

On the left side, you'll see information about the type of objects in the underlying list ("List Item Type"), and below that, information about the list itself ("List Type").  If the ObjectListView is sorted, the sort properties and sort direction of each are listed.  Below that is the current filter expression, if any.  If you're using a filter predicate (as I am in the example), it will tell you that.

The right side shows two tabs.  The one on the top ("View") shows the list items that are currently exposed by the ObjectListView, in the order defined by the current sort, and excluding any items that are filtered out.  This is exactly what you would see in a foreach loop, enumerating the items in the ObjectListView.  The second tab ("List") shows all of the list items in the underlying list, in the order in which they appear in the list.  Cool, huh?

But wait, there's more!  If you're having problems getting ObjectListView to work the way that you expect it to, check out the Analysis button in the lower left.  If you click that, you'll see a synopsis of how the list and list item types work with ObjectListView.  It will tell you about any potential problems, and recommend a solution.  Here's what it looks like:

I hope that the visualizer is helpful.  Debug visualizers are really not very hard to write, and I encourage you to write your own for any complex types that you're coding up.  Take a look at the source in ObjectListViewVisualizer.cs to see how to do it.  The only significant constraint on your code is that the type you're visualizing needs to be serializable.

Enjoy - and please don't hesitate to speak up if you have questions or thoughts about ObjectListView!