We are moving!

I've decided to move the blog to a new hosting service, blog platform and domain name.

The new address is http://blog.digitalfugu.com

I've moved all our posts and comments to the new site. Too bad I can't get Google to map it's existing spider records to point to the new site.

See you at the new place.

.NET 2.0 App Recomplied after .NET 3.0 Installed Crashes

We've been working with .NET 2.0 for a while now and having a grand old time with it but have started to look at some of the .NET 3.0 and 3.5 technologies lately. We found that one of our Click-once applications was having problems after being recompiled. The error we received when we tried to launch the application through Click-Once was:

Could not load file or assembly 'WindowsBase, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

At first we didn't notice that this was a version 3.0 assembly and thought that .NET 2.0 SP1 might fix it. Of course, it didn't. We checked all of our dependencies with Dependency Walker and Process Explorer but couldn't find any reference to WindowsBase.dll. We also found that if we had .NET 3.0 on the client or on the click-once web server it worked fine. If both the client and the click-once server didn't have .NET 3.0 installed, then it failed horribly. This lead us to think that maybe, just maybe, it wasn't really our application but the Click-Once assemblies created by Visual Studio 2005.

The real problem turns out to be something completely not what we expected. It was the Windows Workflow Foundation Extensions for Visual Studio 2005 that caused the problem. For some reason, the WF Extensions for VS 2005 caused the Click-Once assemblies to require WindowsBase.dll from the 3.0 framework.

The solution was simple:

1. Close the solution
2. Uninstall the WF Extensions (I rebooted afterwards just for kicks.)
3. Re-open the solution
4. "clean" the solution
5. Re-build the project
6. Re-publish to our Click-Once server

After that we were home free. I suspect that we might also have gotten away with openning the solution in Visual Studio 2008 and targeted the 2.0 framework for the build.

What reference am I missing?

Wow. I've just started working with VS 2008 and WF and I ran into the coolest thing. I tried to build my solution and got the following error:

Error 2 The type 'System.Workflow.Activities.ExternalDataEventArgs' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. C:\Documents and Settings\xyz\My Documents\Visual Studio 2008\Projects\p1\p1\p1PageFlowService.cs 13 62 p1PageFlowService

I've never had any version of Visual Studio tell me which reference was missing.

As much as I hate to sound like I've been drinking the Kool-aid... Good going Microsoft!

WebEx Alternative: Microsoft SharedView

I just ran across a little advertised free Microsoft application called SharedView. I suspect that this might be Microsoft's attempt at a WebEx killer.

SharedView is a desktop sharing application that allows you to share specific applications or your entire desktop with other SharedView users. It uses Microsoft Passport or Microsoft Live accounts. One party shares and the others can view. However, my favorite feature of Shared View is that viewing parties actually get their own mouse pointer and are able to highlight on the shared application or desk top. No more trying in vain to explain what area you are talking about when you can just point and highlight. Additionally control of the shared application or desktop can be requested participants and delegated by the sharer.

From my brief test drive with it, my only complaint is that it doesn't do voice over IP. A colleague of mine pointed out that it can be advantageous to do audio over the phone any way to avoid network latency. Good point.

You can download it for free from http://connect.microsoft.com/site/sitehome.aspx?SiteID=94

Did I mention that it was free? Check it out for your next online collaboration or product demo.

Click-Once Applications and Minimum Version Requirements

So we are working on Click-Once from web only. This means that the minimum requirement fixing that we did in the last post wasn't needed. We actually had to remove that requirement because web only deployments' manifests can't take a minimum version. I suppose this makes sense because if you are running from the web, you control the version that is posted live at given time.

Cool.

Publishing and Minimum Required Version Settings

Wow, more fun with publishing. I grabbed a new source copy of one of our projects to enable click-once query string parameters and tried to build it but got the following error:

Specified minimum required version is greater than the current publish
version. Please specify a version less than or equal to the current publish
version.

Huh? What was that supposed to mean. I immediately suspected that it was something to do with the publish properties configured in the project properties since I had already been mucking around in there earlier in the day on a different project. I checked out the publish "Updates..." section of the properties which set the minimum required version to be 0.0.0.10. Logically I changed the publish version to 0.0.0.11 and tried to build the project again. No dice; Same error.

As it turns out, it is a bit convoluted, but simple to resolve this. There doesn't seem to be a lot via Google search on it, but I did eventually find it on a Microsoft news group archive. Credit for this goes to David B with discussions.microsoft.com.

1. Go to the project's properties and click on the Publish tab.
   

2. Click on Updates; note the version numbers listed here

3. Turn off "Specify a minimum required version for this application" and
   click OK

4. Update the Publish Version to match or exceed the Update version numbers.

5. Save the new properties and Build the project

6. Go back and turn on "Specify a minimum required version for this
   application" and click OK.

Thanks Mr. B.

Click-Once Applications and URL Parameters

We have a number of .Net 2.0 Windows applications that are to be converted to Click-Once deployed applications. The problem that we had was that these applications are launched with command line parameters, which are not available when running off the web using Click-Once deployment. So the solution was to grab the same parameters from the URL query string parameters. No problem just use the following code to grab and parse them. The real problem came later.

public NameValueCollection GetQueryStringParameters()
{
NameValueCollection nameValueTable = new NameValueCollection();

if (ApplicationDeployment.IsNetworkDeployed)
{
if (ApplicationDeployment.CurrentDeployment.ActivationUri != null)
{
string queryString = ApplicationDeployment.CurrentDeployment.ActivationUri.Query;

if (!string.IsNullOrEmpty(queryString))
{
nameValueTable = HttpUtility.ParseQueryString(queryString);
}
}
}

return (nameValueTable);
}

When I went to run this code on my local machine as Click-Once, I wasn't getting any thing in the ActivationUri. It was null all the time. As it turns out you have to modify your project properties to allow it like so:

1. Right-click your project
   
2. Select "Properties"
3. Select the "Publish" tab
4. Click the "Options" button
5. Check "Allow URL parameters to be passed to application"
6. Click "OK"
7. Re-publish your application

Your application should now be able to get the ActivationUri.

Back from Asia

Wow, been a while since I've added a new entry. I had a great 5 week break in Asia and am back at the grind. Look for new posts soon.

Contacts don't show up in Exchange 2007 Global Address List

It's been quite some time since our Global Address List has worked properly. All of our employees used to show up in there just fine, that was under Exchange 2003. After we upgraded to Exchange Server 2007 everything went sour. New mailboxes and users showed up in the GAL but not the mailboxes and users that existed before the upgrade. We'd looked into this a couple of times, but did not find a resolution to the problem until yesterday.

In the end our problem was that the Mail attribute for our users didn't match the default SMTP address configured in Exchange. The fix was relatively easy, make them match. This can be done one of two ways. The first, is to use adsiedit.msc to edit each user's Mail attribute so that it matches the default SMPT address. adsiedit is included in the Windows 2003 Support Tools and can be installed from the Tools folder in your Windows 2003 CD.

1. Start -> Run -> Adsiedit.msc to start adsiedit
2. Expand the Domain node until you get to your users
3. Right-click on each user and select properties
4. Scroll down to the Mail attribute
5. Click "Edit" and an edit dialog will pop-up
6. Enter in the default SMTP email address configured in Exchange
7. Click "OK", "OK
8. We are done

This is fine if your company is a small-ish start up like ours. If you have more than 10 employees, you'll want to do the following instead.

1. Start the Exchange 2007 Management Shell
2. Type the following to find out who has this problem:
   
   get-mailbox -resultsize unlimited | Where-Object {$_.PrimarySMTPAddress -ne $_.WindowsEmailAddress}
   
   
3. And then the following to fix it:
   
   get-mailbox -resultsize unlimited | Where-Object {$_.PrimarySMTPAddress -ne $_.WindowsEmailAddress} | foreach { set-mailbox $_.identity -windowsemailaddress $_.primarySMTPAddress }
   

Now you can either wait for Exchange to do its update thing or you can force it to update the GAL. If you have a large number of users I would suggest that you just let Exchange do its thing on its schedule, but if you would like to see it right away, do the following (By the way, I'm assuming that you are using Outlook as an email client)

1. Start the Exchange 2007 Management Console
2. Expand the Organization Configuration node, select Mailbox, then click the Offline Address Book tab
3. Right-click Default Offline Address Book and select Update from the pop-up menu
4. Click Yes in the dialog that comes up to confirm that you want to update
5. Wait.
6. Open Outlook
7. Click Tools -> Send/Receive -> Download Address Book
8. Make sure that "Download Changes since last Send/Receive" is checked
9. Click OK
10. Check that you can see all the addresses you think you should see in the GAL through Outlook.
11. We are done

Update: Showing Form Without Stealing Focus

Remember I was using an API call to ShowWindow to show our custom window w/o stealing focus but had to set the visibility property programatically to get the form working properly? No? That was what we were doing but we've found something much cleaner.

More digging through MSDN showed that you can override a form's ShowWithoutActivation property to always return true to get the same effect. This allows you to use the normal Form.Show() method and all it's automatic goodness. However, this is only available in .Net Framework 2.0 or later. If you are in the 1.0 or 1.1 world, you'll need to do the P/Invoke to call the ShowWindow API.

The code looks like this:

protected override bool ShowWithoutActivation
{
get
{
return true;
}
}

It is like magic. I'm liking it a lot.