Difference .Net/Win32 with missing libraries?

[ic2]

I was thinking a bit more about my earlier remark that I rarely update X#, partly because my 2.7 works for everything I need in my code my main concern, real Intellisense improvements and speed of use in VS is planned for the version after 2.8c as intended by Robert. That's one of the 2 main reasons I haven't updated to 2.8 (or more precise: I rolled back the update after some new compiler errors in ADS code which will most likely now work after some rewrites in 2.8 anyway but I haven't reinstalled a 2.8 yet).

The 2nd reason is that I have to replace DLL's at client site and I just realize why this is such an issue. When I would miss a DLL in VO, not very likely as nothing changed for years, I will get a clear error window when starting the VO created program, e.g. The code execution can not proceed because VO28EOLE.DLL was not found.

This will continue until every DLL is present.

But recently an X# created program didn't start without any message. It took me a very long time before I found that I had issued an earlier version accidentally which still contained a reference to the Vulcan DLL's which I removed in the latest version and hence also in the installation at the client site. I could only find some clues by digging deep into the Windows Event log.

Is this another disadvantage of .Net compared to VO or can I change something to get the same clear message for missing DLL's in X# programs?

Dick

[Jamal]

Dick,

I assume this is a Winforms app. In your Start method, wrap the form show method with TRY, CATCH and FINALLY block and check for the exception. I have not tried it, but if it does work for you, let me know.

There is also C# code out there to check for referenced assemblies: https://docs.microsoft.com/en-us/dotnet ... ew=net-5.0

Jamal

[wriedmann]

Hi Dick,
to check startup errors about a missing DLL please see this thread:
https://www.xsharp.eu/forum/suggestions ... cluded-dll
and here is my code to deal with it:

Code: Select all

class ProdPlan.XStartupCode
[STAThreadAttribute];
static method Start as void
	local oSB as System.Text.StringBuilder

	try
	Functions.Start()
	catch oEx as Exception
	AllocConsole()
	oSB			:= System.Text.StringBuilder{}
	Output( oSB, "An unhandled exception has occurred" )
	Output( oSB, "===================================" )
	do while oEx != null
		Output( oSB, "Exception: " + oEx:Message )
		Output( oSB, "Callstack:")
		Output( oSB, oEx:StackTrace )
		Output( oSB, "" )
		oEx				:= oEx:InnerException
	enddo
	Output( oSB, "===================================" )
	Output( oSB, "Press return to close the application" )
	Wait()
	System.IO.File.AppendAllText( System.IO.Path.Combine( AppDomain.CurrentDomain:BaseDirectory, "ApplicationError.log" ), oSB:ToString() )
	end try
	return

static method Output( oSB as System.Text.StringBuilder, cText as string ) as void
	oSB:AppendLine( cText )
	Console.WriteLine( cText )
	return

static method Wait() as void
	Console.ReadLine()
	return

[DllImport("kernel32.dll", SetLastError := true)];
[return: MarshalAs(UnmanagedType.Bool)];
static extern method AllocConsole() as logic

[DllImport("user32.dll", CharSet := CharSet.Ansi)];
static method MessageBox(hwnd as IntPtr, lpText as string, lpCaption as string, uType as dword) as int pascal

end class

[STAThreadAttribute];
function Start() as int
	local oApp as App
	oApp 		:= App{}
	oApp:Run()
	return 0

HTH

Wolfgang

[ic2]

Thanks Wolfgang, Jamal for your reply. This is actually a WCF program (so not WPF or WInforms) but I see that error handling should show the error. I did however already log the exception:message as below and I have checked the log and did not find the missing DLL message there so apparently it doesn't always work contrary to the built in VO reporting which, unfortunately in a way, is again superior to .Net.

Code: Select all

	Catch exception As System.Exception
		LogEvents("IC2WebExchangeWCF",0,Null_Object,"Exception from start "+exception:message,0,"")									// Added logging on runtime error 7-11-2015

Dick

[wriedmann]

Hi Dick,
please look at this exact message from Robert:
https://www.xsharp.eu/forum/suggestions ... -dll#13777
Wolfgang

[Jamal]

Dick,

Please see the following discussion about the .NET CLR loader and Win32 loader mechanism and differences.

https://stackoverflow.com/questions/296 ... by-the-clr

Thanks Wolfgang, Jamal for your reply. This is actually a WCF program (so not WPF or WInforms) but I see that error handling should show the error. I did however already log the exception:message as below and I have checked the log and did not find the missing DLL message there so apparently it doesn't always work contrary to the built in VO reporting which, unfortunately in a way, is again superior to .Net.

Code: Select all

	Catch exception As System.Exception
		LogEvents("IC2WebExchangeWCF",0,Null_Object,"Exception from start "+exception:message,0,"")									// Added logging on runtime error 7-11-2015

Dick

[ic2]

Hello Jamal,

Please see the following discussion about the .NET CLR loader and Win32 loader mechanism and differences.

That's very interesting. It could explain why, despite the error handler, nothing was reported but my program simply didn't start without a trace.

It confirms once more that .Net is full of design flaws. But what else could one expect from Microsoft?

Dick

[robert]

Dick,

I strongly disagree that delaying loading DLLs until really needed is a design flaw.
I think this is a well thought decision.

Btw: For X# things works a bit differently:
We add special code to every DLL compiled with X# (at least in the non-core dialects).
When the main app is started then this startup code is executed, to make sure that INIT procedures are all run at startup time and also to make sure that types in external libraries become available so they can be created with CreateInstance(#TypeName).

Robert

[wriedmann]

Hi Dick,
I would even go further than Robert: for me a delayed DLL load is very important.
I had asked for that many years ago for VO, and since that was not possible, I implemented something for not-always-used DLLs like printing, zipping and some more, to speed up the loading of my applications.
And AFAIK the company of Arne has a system to load nearly all DLLs delayed.
I don't think that all decisions that Microsoft has made for .NET are good decisions (IMHO they have several design flaws in WPF), but after all .NET shows that they have learned a lot from earlier systems.
Wolfgang

[ic2]

Hello Wolfgang, Robert,

Hi Dick,
I would even go further than Robert: for me a delayed DLL load is very important.

I don't deny that; after all thanks to the JIT compiler starting any .Net program with delayed DLL loading takes a lot more time than a Win32 program like from VO, with loading all DLL's.

The price we pay for .Net programs not being even slower than they already are however is that there's no (reliable) way to be informed that a DLL may be missing.

It has taken me a few hours while in VO I would have seen it immediately.

Dick