I have an application with lots of projects in it.The main project, which compiles to the EXE has references to two Janus assemblies and to one of my own assemblies (the dll, not the project). Additionally, I have about 15 assemblies that use these components and point to their dll’s in the same location as the main exe does. Somehow, something got out of whack and in design mode the main exe couldn’t “find” these 3 assemblies. I got that fixed and at the same time had to make some different changes to two of the other assemblies. After doing my update via clickonce, I couldn’t load these two assemblies in the application on client machines. I did a lot of recompiling and redeploying of specific assemblies so that I could continue with my minimal impact ClickOnce update.This means that I don’t republish and redploy the ENTIRE application, but can just move only the assembies I need to the webserver and recreate the manifests there. (I need to write an article on this).

When I tried to access the functions that loaded these assemblies, there was an error complaining about matching assemblies listed in the manifest.

“The located assesmbly’s manifest definition does not match the assembly reference”

When I opened up these projects in VS2005 and looked at the references, those three assemblies had this “<system could not find the reference specified>” in the value where the path should have been.

So, I had to load up every one of these projects and in each one, remove the existing refs to those 3 assembiles and re-add them in.

Then I rebuilt the entire solution and had to run the full publish utility on my development machine and redeploy the entire application to the web server – a two part process. Two-part, because the dynamic assemblies do not get picked up by the publish tool. I have to deploy the results of the publish, then copy that folder into a new folder (next version number), add all of the dynamic dll’s, then rebuild the manifests. (That’s part of the trick I will write about in the aforementioned article.) The whole app is about 11MB. Copying this over VPN with 350K upload speed takes longer than I have patience for, but that’s life.

Nevertheless, after a lot of copying, pastng, manifest buildng adn testing, I was able to get the whole re-jiggered app deployed without requiring the dreaded un-install. The end-users won’t even notice a thing tomorrow morning when they get back to work.

Don’t Forget: www.acehaid.org

(note: for those of you who need this clarification – eg the anonymous commentor who gave me the big lecture 🙂 – the title and the last sentences of this post are intended to be sarcastic. Sheesh.)

In my talk on Preparing WSE3 Web Services for WCF at DevConnections, I was asked the dreaded question: do these work on the compact framework?

Nobody likes to get this question, because the answer is just way too embarrassing.

The answer is “No”.

This has been the cause a lot of ruffled feathers in the CF and Web Services community. Casey Chesnut , our resident genius, even wrote his own implementations: cfWSE and cfWSE2.

The last version of the WCF story that I heard was that R1 will not have it, but R2 will. The WCF footprint is small which will help enormously. But R2.

To top it off, though I don’t have a PPC and didn’t see this myself, I am astonished to learn through Softwaremaker, yet another place where security has been set aside: Passport logins. On the web, we get a login and a masked password, along with options to remember the login, password or both. Not only are those options gone with the PPC interface, but the password is not masked! Hello?

I suppose that it is another indication that people who use PPCs or write applications for them, are just not doing anything important enough to require security. I suppose.