VB.Net Appliction stops working when version is updated

  • Thread starter Thread starter Workaholic
  • Start date Start date
W

Workaholic

Hi,

I have a problem that I have now seen on two different servers.

I have a VB.Net application that is installed on the servers. It works
fine on both servers. If I make a change to the application on my
development PC, recompile it and test it on the local development
machine, it still works fine. However, if I then copy the new EXE file
from the development PC to the target servers (and overwrite the
original EXE on the servers), then the application stops working on the
servers. Having added lots of message boxes throughout the code to see
what it's doing, it seems that the first subroutine is called
successfully, however the 2nd subroutine is never executed. The message
box immediately before the "call xxx" displays some output, but neither
the message box inside the subroutine, nor the message box after the
subroutine, are ever displayed. The application is just hung and has to
be killed from Task Manager.

Here is the weirdest thing. If I uninstall the application from the
server, then install the new version of the application, then it works
fine. It's exactly the same EXE file, but now it works.

Can I not copy a newer VB.Net executable onto the target machine? I'm
really stumped because Windows is NOT rolling back to the previous
version of code, because I AM seeing my debugging message boxes up to
the point the 2nd subroutine is called.

Can anyone help me? This is driving me nuts, and it's a really major
hassle to have to back up all the data, uninstall, reinstall, and
re-import all the data every time I make even a tiny change to the
code.

Thanks for your help
 
Workaholic said:
I have a problem that I have now seen on two different servers.

I have a VB.Net application that is installed on the servers. It works
fine on both servers. If I make a change to the application on my
development PC, recompile it and test it on the local development
machine, it still works fine. However, if I then copy the new EXE file
from the development PC to the target servers (and overwrite the
original EXE on the servers), then the application stops working on the
servers. Having added lots of message boxes throughout the code to see
what it's doing, it seems that the first subroutine is called
Click to expand...

It sounds like it may be throwing an exception somewhere that you are
not seeing. If you check the Event logs on the machine that executes
the code from the server does that reveal anything?

Have you used Try Catch exception handling liberally throughout your
code so that any exceptions are caught?

Obviously, if the code is displaying *some* of the new message boxes
you added but not getting to some down the line, then the point of
failure lies between those two points. Have you examined what calls
are being made there? Is is calling into any other .dll's?

What about versioning? Are you relying on VB to automatically
increment the version? For example in the AssemblyInfo.vb file, is the
version set to something like this: 1.0.* using the asterisk notation?
If so, then maybe some of your assembly dependencies are wrong. You
should always explicitly set the version number for your assemblies.

Hope this gives you some ideas,

Good luck.
 
Hi Chris,

Many thanks for your advice.

I don't think the TRY/CATCH and other error handling is the problem,
because if I uninstall and reinstall the application then everything
works fine. The issue only occurs if I copy in a later EXE file without
doing the complete MSI uninstall and re-install

I checked the version in AssemblyInfo.vb and it is indeed set to
<Assembly: AssemblyVersion("1.0.*")>. I will try setting this to be a
specific value.

I am still confused about this, though. I could understand it if the
new code was generating errors, or if the new code was not being
executed at all (e.g. if Windows or .Net was rolling back to the "last
known good" version), but I can't understand why the code will enter
the first subroutine, but not the second subroutine. I also looked
through the event logs, but there was nothing in there at all.

I was hoping somebody could say "you can't copy in a new EXE because of
xyz", or "you need to do xyz first" - but maybe this is stumping
everyone else too!

Thanks again for your help Chris

Laurie
 
Workaholic said:
Many thanks for your advice.
Click to expand...

I'm sorry I don't have an "Aha, your problem can be resolved by x....."
type of answer.
I don't think the TRY/CATCH and other error handling is the problem,
because if I uninstall and reinstall the application then everything
works fine. The issue only occurs if I copy in a later EXE file without
doing the complete MSI uninstall and re-install
Click to expand...

I only brought it up in case there was some exception that was not
getting caught and that having adequate exception handling would be
sure to catch it.
I was hoping somebody could say "you can't copy in a new EXE because of
xyz", or "you need to do xyz first" - but maybe this is stumping
everyone else too!
Click to expand...

I have done that many times so I know that it is possible to simply
copy a new exe in. That's why I suggested about checking the version
numbers because if there were assemblies dependent on a certain
version, then copying in a new version might cause a conflict.
 
Back
Top