4

I faced very strange behaviour - after I overwrite .NET exectables with new versions from network drive it cannot start. When try to start from Windows Explorer it shows me following error:

[Window Title]
C:\Programs\zzz\clients.net\zzzNet.exe
[Content]
C:\Programs\zzz\clients.net\zzzNet.exe
The application has failed to start because its side-by-side configuration is   incorrect. Please see the application event log or use the command-line   sxstrace.exe tool for more detail.

I tried to execute following commands:

SxsTrace Trace -logfile:SxsTrace.etl 
SxStrace Parse -logfile:SxSTrace.etl -outfile:SxSTrace.txt

And got following result:

=================
Begin Activation Context Generation.
Input Parameter:
    Flags = 0
    ProcessorArchitecture = AMD64
    CultureFallBacks = en-US;en;ru-RU;ru
    ManifestPath = C:\Programs\zzz\clients.net\zzzNet.exe
    AssemblyDirectory = C:\Programs\zzz\clients.net\
    Application Config File = C:\Programs\zzz\clients.net\zzzNet.exe.Config
-----------------
INFO: Parsing Application Config File     C:\Programs\zzz\clients.net\zzzNet.exe.Config.
INFO: Parsing Manifest File C:\Programs\zzz\clients.net\zzzNet.exe.
    INFO: Manifest Definition Identity is (null).
    ERROR: Line 0: XML Syntax error.
ERROR: Activation Context generation failed.
End Activation Context Generation.

It is quite simple .NET application (1 exe + 8 dll files). It was built for .NET 3.5 Client Profile.

I not defined any special "manifest" there. Just clicked "New Windows Forms Project" in Visual Studio and developed it. Also app.config does not contain anything special - only primitive standard settings - appSettings and userSettings sections. On PC where I developed it all is perfectly works. Problems only began when I copy these binaries to this particular VM and try to start.

Also please note - these executables were not installed in GAC or such, I just copied them into a folder on VM and started. And when it was 1st time all was working fine.

So, the problem pattern is following:

  1. Copy .NET execuatbles to new VM (it is Win 7 x64), run it, all is working fine. Close it.
  2. Build new version of .NET execuatbles on host PC, copy new .NET execuatbles to VM (with files overwriting).
  3. Try to start - got mentioned problem.

After some shaman-style actions (like OS reboot, etc) it begin to work but why that happened at all?!

Why replacing .NET executables with new versions is causing SUCH HUGE PROBLEMS?!

Also the BIG QUESTION - is there any special procedure to replace .NET executables to keep them working? Because it is a new app development, I do not want lost so much time on every new executables installation. :-\

Could you please help? Because it looks completely weird!

Thank you in adance.

PS. I checked all VS projects - all they have PlatformTarget=AnyCPU. Also in run-time I can see ProcessType=MSIL (I show this info in AboutBox for application). So, there is no mix of x86/x64 binaries.

dmitry_bond
  • 378
  • 1
  • 3
  • 15
  • 1
    if I remember correctly problem is that not all your dll/exe are client profile. or some are complied on x86/x64 use all as any CPU if possible my advice is DON'T use client profile. work only vs full .net. it was a bad try to create a smaller .net in a world with slow internet. also win7 supports .net 4.5 are you sure you need this project to be 3.5? – Nahum Mar 30 '16 at 07:57
  • Ya, I know about it. That is not the case. I checked all projects - all have PlaformTarget=AnyCPU. Also in run-time I can see ProcessType=MSIL. – dmitry_bond Mar 30 '16 at 09:32
  • The manifest in the EXE file containing bad XML is a fatal problem. But that isn't very plausible and that doesn't repair itself with a reboot. Disable your anti-malware product and try again. If it is Avast then uninstall asap. You can look at the manifest btw, File > Open > File, pick the EXE, open the RT_MANIFEST node and right-click resource ID 1 > Export. – Hans Passant Mar 30 '16 at 10:13
  • As I mentioned - there are no any manifests at all! So, that is wrong error message in Microsoft component. Antivirus is ESET NOD32. – dmitry_bond Mar 31 '16 at 07:28
  • In case the project is managed C++/CLI, make sure that the `AdditionalManifestDependencies` string is valid. also, you can read the embedded manifest by using `CFF Explorer` -> `Resource Editor` -> `Configuration Files` – itsho Feb 09 '21 at 11:50

1 Answers1

0

It seems that was related to mapped network drive behavior. When I copied new files from network drive folder it copied wrong files - a strange random mess of new files and older ones (which were there before I updated them on VM host).

The scenario to make it working:

  1. on VM: delete all files in a folder on network drive
  2. on VM host: copy new files into a folder which is mapped as network drive on VM
  3. on VM: copy files into target folder
  4. on VM: run application - it works now

Weird thing. I remember I have seen something similar with Windows Explorer on Windows 2008 behaviour when copying updated win32 binaries.

dmitry_bond
  • 378
  • 1
  • 3
  • 15