Problem upgrading dll

You can't just copy and paste the latest AutomaticUpdater with your app. You have to build (i.e. recompile) your application with the latest AutomaticUpdater.

By include I mean that I upgraded my reference to the new dll. This included a recompile of course of my app.

Ok, I need more information on the error. Is the AutomaticUpdater throwing an exception? Please copy & paste the full exception. Or is it something else that is causing the errors?

Hello again

The full stacktrace is:

at Nemo.MainWindow..ctor(Boolean bootStart) at Nemo.App.<>c__DisplayClass1.<OnStartup>b__0() in c:\Documents and Settings\Arj\Dokumenter\iola\projekter\merged-nemo-wpf\codename-nemo\App.xaml.cs:line 46 at Nemo.SingleInstance.Run(Func`1 showWindow, String[] args) in c:\Documents and Settings\Arj\Dokumenter\iola\projekter\merged-nemo-wpf\codename-nemo\common\SingletonWPF.cs:line 100 at Nemo.App.OnStartup(Object sender, StartupEventArgs e) in c:\Documents and Settings\Arj\Dokumenter\iola\projekter\merged-nemo-wpf\codename-nemo\App.xaml.cs:line 43 at System.Windows.Application.<.ctor>b__1(Object unused) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)

So as you can see, the error occours when we try to create the initial WPF window. The Window uses the automatic updater control.

I'm not seeing how this is related to the AutomaticUpdater at all. Can you please explain.

Well the error is that for some reason my program fails with could not load type 'VoidFunction' from assembly 'AutomaticUpdaterWPF. So that seems to indicate some problem with AutomaticUpdaterWPF does it not? I can't reproduce it locally, but I have gotten quite a few of these errors from people running our program after upgrading.

I'm looking at the crash stack trace and it looks like the problems are caused by whatever single instance code you have. But if you can reproduce this, please let me know.

Hmm. That sounds a bit strange to me that it should have something to do with our singleton stuff. The reason why I started this thread was that we have been running automatic updater for more than a year and havn't had any problems like this before. But after upgrading automatic updater as part of our program update I started getting these errors. So there seems to be some kind of problem with upgrading automatic updater.

I must say that we had a few related problems before with the google libraries that we bundle. But not in the scale that we get for this error. When I tried searching for what the problem could be with the google library, the best explanation I got was that it was because the dlls might be corrupt and the users machine.

Hello again

I have a theory now. Before automaticupdater 2.6.16, we had our own function that did the same thing as CloseAppNow does. Then we used a VoidFunction as the signature. I can see that I'm getting the error because an old version of our program is trying to read this VoidFunction symbol in the new automaticupdater library. So it seems like during the upgrade to the new version of our program, our old version somehow get hold of the new version of automaticupdater. How can this happen?

If you reference the AutomaticUpdater in the wyBuild folder, when you update wyBUild the latest version of the AutomaticUpdater gets installer. Then when you rebuild your app the AutomaticUpdater gets updated in your "bin" folders.

So you included the latest AutomaticUpdater with your app.

I'm not referencing the AutomaticUpdaterWPF.dll from wybuild. I've always compiled my own version (because previously I needed changed), but now just out of habit. This is how I'm including AutomaticUpdaterWPF.dll with my program in the updater:

https://dl.dropbox.com/u/195530/updater.jpg

It's pointing to the folder where I keep the latest version of my app. So this is what happened:

In version 1.1.2 of Nemo Documents I have included a self compiled version of AutomaticUpdaterWPF.dll 2.6.14.In version 1.2.0 of Nemo Documents I have included a self compiled version of AutomaticUpdaterWPF.dll 2.6.16.

After releasing 1.2.0, I'm getting errors that version 1.1.2 of Nemo Documents can't find VoidFunction in AutomaticUpdaterWPF.dll 2.6.16? So this means that somehow AutomaticUpdaterWPF.dll must have gotten updated, but Nemo Documents was stilling running as 1.1.2. And they don't work together. Hence the crash.

How can this happen? I was under the impression that when my program is getting updated, that it closes my app. Installs all the updates, if anything fails, rolls back. Otherwise it starts up the new version of the program. That's why I'm so puzzled seeing an old version of my app referencing a dll that was including in a newer version of my app.

If your update fails to install then wyUpdate rollsback the installed files. I'm not sure how you got the new version of AutomaticUpdater with the old version of your app. Can you reproduce this behavior?

No, that is the strange thing. I can't reproduce it here on my machine or any of my virtual machines

I now had a machine where the error was on. I inspected the program files folder for my program and could see that the exe file was not updated, that the dlls was updated and that client.wyc was updated. Meaning running wyupdate manually in that folder also didn't work.

Can you reproduce this behavior? That is, can you create a circumstance where wyUpdate is only updating some files? Because we can't reproduce it here. Make sure you're using the latest wyUpdate.

No still can't reproduce the problem. It didn't happen on my machine, I only got access to a machine that failed to update.

Also I can't force my clients to upgrade their wyUpdate. They have what was the latest when they installed the version of our program that they upgraded from.

We had what looks like 120 errors (some of them might have tried to start the program multiple times) yesterday. So I guess I don't need to mention how much this situation sucks 😐

Are you using a custom version of wyUpdate? (Did you modify the source)? Or are you hosting wyUpdate on your own servers?

What's the version of wyupdate before/after the update?

We had what looks like 120 errors (some of them might have tried to start the program multiple times) yesterday.

This error happened 120 times? Or 120 errors as the result of this one problem?

We use just a normal wyUpdate. 1.1.0 of our program has wyUpdate 2.6.14. The version they are upgrading to 1.2.4 or 1.2.5 has wyUpdate 2.6.18. We are not hosting it ourselves.

The error happened 120 times yesterday. It happens when the program starts up. The 120 is maybe about 100 different users is my best guess.

We need more information or a way to reproduce this. We haven't been able to reproduce this in any of our tests.