xsharp.eu

After lots of changes Frank, who is working on preparing a X# conversion of a large project of ours, managed to have a compiling solution. It has still many warnings but it shows 0 errors. Despite that it doesn't start. When we set a breakpoint on the first line of the function Start (see below) and choose Start Debugging (Debug version of course) I see Build, appear again and the green progress bar fills quickly, showing some of the libraries (much faster than during a normal build). And that's it. It never reaches the breakpoint. No errors. You still see 0 issues found.

I tried a Clean solution and Rebuild, same effect. Every time we restart I see the same Build-like activity.

What can I try next?

Dick

[STAThread] ;
FUNCTION Start() AS VOID
LOCAL oApp as AppSettingsKL
__SetAppObject(oApp:=AppSettingsKL{} )
oApp:Start()
ApplicationExec(ExecWhileEvent)
return

Dick,

ic2 wrote:

Code: Select all

[STAThread] ;
FUNCTION Start() AS VOID
	LOCAL oApp as AppSettingsKL
	__SetAppObject(oApp:=AppSettingsKL{} )
	oApp:Start()
	ApplicationExec(ExecWhileEvent)
	return

I would recomment to add a TRY .. CATCH in the start code and display the error.

Something like Robert

Hello Robert,

It doesn't even reach FUNCTION Start() AS INT. If we put a breakpoint in the first line possible it still is showing the Build messages. And I would not expect Build messages at all, when I choose F5 or Ctrl F5.

EDIT:

This is what we see in the Output window, again, when we run INSTEAD OF bUILD:

Build started...
------ Build started: Project: _Algemene Functies, Configuration: Debug Any CPU ------
Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.

(Followed by again all the libs, their warnings and xx Warning(s), 0 Error(s)

========== Build: 14 succeeded or up-to-date, 0 failed, 0 skipped ==========



What else can we do?

Dick

We see the cause....but not -directly- the solution.

It's a Side By Side error because we use a X#/C# DLL. Thanks to Windows such an error remains hidden until you think of looking in the Windows Application log.

In VO it's a matter of the correct manifest but apparently that is not "XPorted" to work correctly in X#.

What should we do in X# to correctly configure that?

EDIT: eventually we can of course integrate the contents of the lib in X# we concluded. But is there a comparable way of integrating external libs without the need for RegAsm in X#? Or is is never needed?


Dick

Hi Dick,

What is the error message you get in the log?

Hi Dick,
I would add the dependency of the DLL directly in the X# program.
But of course also the trick with the manifest should work.

Do you have tried to remove it and add it manually?

Wolfgang

Hello Chris, Wolfgang,

The application log showed the classic "Side by side" error. With a quite bit of effort we could remove the resources connected with Manifest and as we have 30 places where the OleAutoObject is used (to call the X#/C# DLLin VO) it makes more sense indeed that we replace this with a direct call after adding the X# and C# code of the DLL into the solution.

Tomorrow Frank will update X#, re-apply the references to the correct X# DLL's and copy those in the work directory as version numbers seem to be the current issue. We are getting closer to a running X# version of a huge VO project, of course after it compiles and starts there will still be plenty of issues. Eventually we have decided that, after making many changes in the VO program, Frank will now make a working version of the current code, and redo what he has done to achieve it once more on the VO version which has been worked on normally in the last few weeks. It seems that Frank has found a very usable GitHub based set of commented commits which he can use as a step by step instruction to redo the changes on the latest VO version at the time of final and definitive conversion.

Maybe a manifest will work in X# as well, but honestly, I have 6 OneNote pages of instructions how to deal with the countless problems errors and issues of a using a manifest so if we can avoid that in X# it is much better for our health.

Dick

Hi Dick,

I really do not know what is the "Classic Side by side error". Unless Wolfgang already knows what you are talking about and can help you out, please post the exact message so I can also try to help as well.

Hello Chris,

When we copy the X#/C# code into the X# project we don't need Side by Side anymore as we do in VO. So that problem is solved.

Below is an example of the "classic Side by Side error" . There are about a dozen possible obscure causes and as usual Microsoft hides the real cause, even hides the error (it can be seen in the Windows Application log only) and has a crappy DOS program, sxtrace.exe to waste the times of programmers to find some hint of the cause.

Dick

Activation context generation failed for "d:XSharpVOTestXSharpVOTest.DBG".Error in manifest or policy file "d:XSharpVOTestDotNetLibForVO.DLL" on line 1. Component identity found in manifest does not match the identity of the component requested. Reference is IC2ExtLibForVO,processorArchitecture="x86",version="1.0.65534.65534". Definition is DotNetLibForVO,processorArchitecture="msil",version="1.0.65534.65534". Please use sxstrace.exe for detailed diagnosis.

Hi Chris,
please let me explain a bit what "Side-by-Side" or shortly "SxS" is:
if you are using a COM module in your application, you have to register it on the machine. That process writes some information about the DLL in the registry.
That has several drawbacks:
- you cannot use different versions on the same machine
- you need administrative rights on the machine to install - copying alone is not enough
- to run the application from a network drive you have to install the COM module first

Since Microsoft recognized itself that is is a problem they added a possibility to overcome that by a sort of dynamic registration of the module at the application start, using a manifest in the application. That works starting with XP SP3.
Unfortunately that process is not well known and has several traps, and a small typo is enough to make the process fail and to block the program start.
But if that process is set up correctly, it works very well, so it is worth the work.
I'm using that a lot to integrate X# code into my VO applications, and nearly every VO application uses at least one X# COM module in this manner.
You can find a sample how to make this work in my preferred IDE <g> here:
https://docs.xsharp.it/doku.php?id=com_module_sample
Wolfgang
P.S. of course, when migrating the application to X#, the same COM module can be used directly as application dependency, using conditional compilation to keep the code portable between X# and VO