Differences Between Development and Build Server Environment

Topics: Prism v4 - WPF 4
May 18, 2012 at 2:58 PM
Edited May 18, 2012 at 3:52 PM

This is using Silverlight 5.

This is a bit of a long shot but, we're seeing some whacky differences between our development environments (Visual Studio 2010 sp1) and our integration test servers (Server 2008 r2).

Currently we've had at least 2 occurrences where everything runs fine in dev, but there are runtime errors on the test server.  99% of the time our deployments to our test server have been working fine (for months) and we use it regularly for client review/acceptance testing.

In one case we had to set IsKeepAlive to true when subscribing to events.

In Dev, if we didn't, the app still ran fine.  No errors and everything worked correctly.  There were some cases before this where even in dev we would see run time errors when IsKeepAlive was not set to true so we started always setting IsKeepAlive to true.  But in this case, in dev it worked, only on the test server did it kill the app at runtime.  This was a nightmare to track down as it would show as simply as a top level object composition failure.  The event subscription was many Imports deep.  Once we set the one value of IsKeepAlive on the one event things were fine again.  And yes, we have hundreds of other events (all set to IsKeepAlive = true for Silverlight).

Yesterday and today I've been facing a similar problem where it runs fine in Dev but gets run-time composition errors on the test server.

I'm currently debugging it so I have no idea what the problem will be this time.

However, my question here is what suggestions does anyone have that can help me make sure my development environment matches my server environment so I can debug and solve these problems in development, not after promoting to our test servers.

My biggest issue is the only way I can debug the test servers is to make code changes (usually commenting out Imports in one file at a time) then building the solution, deploying to the test server, running it, waiting for failure, then reviewing the log files.

This is a horrible way to try and solve a problem.

All suggestions are welcome from trying to fix the environments to better ways to debug on a server.


May 18, 2012 at 3:49 PM

So at this point it looks like this one line is the problem:

private IEventManager eventManager { get; set; }

As you can see, someone coded this as a private property.

When I change it to a public property there are no activation errors.

My problem with this is that in dev, it doesn't matter.  I can leave it as a private property and I get no activation errors from MEF/Prism and the entire application works just fine.

Only when I publish this to our test server does this turn into an activation error when trying to compose the view model to the view.

We have 2 sets of test servers which are set up quite differently.  The application has been working just fine on both until this error popped up (we've been making ongoing code changes so I can't tell for sure at this point when this might have changed).

That private property breaks the app on both sets of servers.

Any insight out there as to why this doesn't cause a problem in dev?  I really wish it did :)

May 18, 2012 at 6:58 PM


Based on your description, it seems that this problem is related to the environment of the testing servers rather than Prism or MEF. So far we haven't been notified of any behavior similar to the one you are describing.

As a starting point you could check if your Silverlight application is running as a full trusted application or medium/partial trusted application in your test servers. For example, this can cause problems when MEF tries to import an instance into a private property / member like the eventManager property you mentioned above. This is described in the MEF programing guide:

If this is not the case, you could also check if the development and testing environments are using the same versions and settings of the .NET Framework, Silverlight, Prism, MEF and any other library / functionality you might be using. Also, I believe you might find the following chapter of the Prism documentation useful when moving a Prism application for development to production / testing:

I hope this helps.


Damian Cherubini