1 My DotNet DLL used from VO is registered using a manifest and MT.exe from VS. That normally works fine, but now I found something strange. I installed my changed programs with all DLL's etc on a another Pc for testing, but got: a Side By Side error, in the log it says:
Unable to create activation context for '(myexe.exe). Unable to find dependent assembly DotNetLibForVO,processorArchitecture="msil",version="1.0.1.1". Use sxstrace.exe for a detailed diagnosis.
I thought probably mt.exe didn't execute, this can cause it, copied the DLL from a few hours earlier from my regular environment which worked fine, and problem was gone.
But now I copied the 'faulty' DLL back from where I kept it temporarily, and this time the exe started without any problem. So with the same files where it didn't start originally.
How is that possible?
2 Another thing I don't understand is this. In the code below a window with the WebVIew2 component, which is the Chromium Edge runtime, is displayed. If that runtime is not installed (it will install automatically with newer W10 updates) the code below should generate yield a runtime error and the RECOVER has some code to ask the user to install (here only the URL execution)
I have seen that working but what happened here was that I briefly see the WPF window, without the (missing) component but instead of reaching RECOVER I get a VO window saying:
No errorblock
Error in Errorhandler
(in the ShowEmailInWebView2 which is the X# method in the DLL starting the display of that window).
Why doesn't the program reach RECOVER?
BEGIN SEQUENCE
bErrorHandler := {|oError| _Break(oError)}
bLastHandler := ErrorBlock(bErrorHandler)
oDotNet:= OLEAutoObject{"DotNetLibForVO.VoDotNetClass"}
IF !oDotNet:Finit
.....
ENDIF
IF !oDotNet:ShowEmailInWebView2(cHTML,cCaption) // When this can't be finalized due to a missing WebVIew2 runtime, it should go to recover
ErrorBox{,Vt(MSG_NOCONNECTION,"No connection")}:Show()
RETURN FALSE
ENDIF
RECOVERShellExecute(NULL, String2Psz("open"), String2Psz("https://go.microsoft.com/fwlink/p/?LinkId=2124703"), NULL_PSZ, NULL_PSZ, SW_SHOW)
END
ErrorBlock(bLastHandler)
Dick
Strange Side By Side issue and error handler question
Strange Side By Side issue and error handler question
Hi Dick,
since I have a bit of experience with X# COM modules and VO applications, building them the with XIDE, a few things:
- do you have checked with sxstrace? Normally that is a really helpful tool. On this page you can find a sample how to use it: https://docs.xsharp.it/doku.php?id=com_module_sample
- for a VO program you should replace "msil" with "win32" (in the manifest).
Wolfgang
since I have a bit of experience with X# COM modules and VO applications, building them the with XIDE, a few things:
- do you have checked with sxstrace? Normally that is a really helpful tool. On this page you can find a sample how to use it: https://docs.xsharp.it/doku.php?id=com_module_sample
- for a VO program you should replace "msil" with "win32" (in the manifest).
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Strange Side By Side issue and error handler question
Hello Wolfgang,
Thanks for your reply. I have not used sxstrace, it's a very clumsy tool which often didn't help me either, apparently contrary to you
I have recreated the setup and this time it worked without issues. I mainly wonder why I got a Side By Side error, which disappeared with another (same way created DLL) and did NOT reappear when copying the 'faulty' DLL back. That's a new chapter in the dramatic Side By Side stories.
I do indeed not have the DLL on X86 and I realize it's somewhere hidden in the Visual Studio heap of output, as a warning. Not sure if that will help to trigger the VO error handler. Normally I would conclude that an error in the DLL would not trigger the VO error handler, but I have seen it working a few times.
Dick
Thanks for your reply. I have not used sxstrace, it's a very clumsy tool which often didn't help me either, apparently contrary to you
I have recreated the setup and this time it worked without issues. I mainly wonder why I got a Side By Side error, which disappeared with another (same way created DLL) and did NOT reappear when copying the 'faulty' DLL back. That's a new chapter in the dramatic Side By Side stories.
I do indeed not have the DLL on X86 and I realize it's somewhere hidden in the Visual Studio heap of output, as a warning. Not sure if that will help to trigger the VO error handler. Normally I would conclude that an error in the DLL would not trigger the VO error handler, but I have seen it working a few times.
Dick