0

The company I work for has recently decided to move to a ClickOnce deployment strategy for one of our internal applications that needs to be run by a hundred or so production computers. The previous strategy of building a .msi and installing worked fine between updates and we never experienced any problems after updates. Now that we have switched to ClickOnce we are experiencing a number of problems. After the initial install everything was working fine until we pushed out our first update. All of the computers successfully updated and ran that software fine for the day. The next morning when they were booted a number of the computers gave the error:

Could not load file or assembly "_______, Version=1.0.0.0. Culture=neutral, PublicKeyToken=null" or one of it's dependecies. The module was expected to contain an assembly manifest.

Where the blank is one of two C# dlls that is part of the application.

We never get these errors in development and I am unable to reproduce the issue on any computers I try. Even one of the production computers doesn't throw the error when I tried restarting it (hard reset and soft reset).

Here are some of the things we have tried:

  • Making sure the main application and all the dlls are built for any CPU as this seems to cause this problem often from our research. This has been verified by looking at the assembly information of the built executable.

  • Made sure all the dlls and manifest files were in their correct place in the ClickOnce folders, comparing them to working computers shows no real difference

It is not even all the computers that go down with each restart, it seems like a matter of chance, some are fine on a particular restart and others are not. These computers have all been imaged to be identical and none of the external dependencies have changed between the two builds so I am having issues finding any difference there.

Any insight from someone that has experienced similar issues and/or knows what could cause these issues in a ClickOnce-deployed application would be appreciated.

Some further details.:

Looking deeper into the particular dll that is having an issue that was on one of the computers it almost looks as if it is just a blank dll as it won't bring up any information on its assembly when I run a utility against it. However it is the perfect size that it should be so it can't be completely blank (408KB). Any clue why that could be? Why would ClickOnce download a blank dll when other computers had gotten the correct dll from the same place and the application had had the correct dll on the original run?

The way we have been 'fixing' this is by uninstalling and re-installing the software which basically fixes it for the day or until the system is restarted. Although we have hit a computer or two that even after a re-install will give the same error even though the initial install was fine.

Hopefully this can help.

KyleC
  • 3
  • 1
  • 3
  • Any idea why the error contains a version 1.0.0.0 when (I assume) it is the update that is being run? Shouldn't it try to load an assembly with an incremented version? – Maarten Aug 11 '14 at 13:03
  • Valid point but this particular dll has not been updated I presume, just the main application not the one being referenced. Could this issue happen if the dll was updated but the version number not incremented? – KyleC Aug 11 '14 at 13:21
  • I assume the publish version (http://msdn.microsoft.com/en-us/library/haeyaeba.aspx) **was** incremented? – Maarten Aug 11 '14 at 13:24
  • What I usually do is create a GlobalAssemblyInfo.cs and link to it from your various projects. That way all assemblies are updated, and therefore all new versioned assemblies will be forced to be downloaded with the new version. See this question: http://stackoverflow.com/questions/2732155/c-sharp-project-global-assemblyinfo - Check the comments about the uniqueness of attributes in the files. – Maarten Aug 11 '14 at 13:26
  • @Maarten Yes the publish version was incremented and the MinimumVersionNumber was also incremented to be the same therefore forcing the update on all the computers without user interaction. I will need to look further into this GlobalAssemblyInfo.cs practice and see if this can help us resolve this issue, if it is due to that un-incremented version number then this should do the trick, thank you. – KyleC Aug 11 '14 at 13:30
  • Could it be that there's simply a conflict of different DLLs in the system? I mean, if the application was previously installed using an MSI, could there be some "leftover" that's interfering? @Maarten: It's very well possible to update one part of the application (for example the EXE file) without updating the DLL version. We have many ClickOnce applications that contain 1.0.0.0 version DLLs, but have experienced up to 20 updates to the main executable. – Thorsten Dittmar Aug 11 '14 at 13:35
  • 1
    @KyleC Please note that is is *not* necessary to change the version numbers on all components for a ClickOnce update! The **ClickOnce version** determines basically the name of the folder the application gets deployed to and the check whether an update is required. You could very well keep all the assembly version numbers as they are forever - they do not matter at all. – Thorsten Dittmar Aug 11 '14 at 13:37

0 Answers0