xsharp.eu

I have recently changed Vulcan references to X#. One exe doesn't work without these Vulcan DLL's in the directory:
VulcanRTFuncs.dll, VulcanVOGUIClasses.dll, VulcanVORDDClasses.dll, VulcanVOSystemClasses.dll, VulcanVOWin32APILibrary.dll

but as you can the in the picture, no Vulcan DLL's are included, nor are these with only non system or X# reference (red underlined).
The project is in a solution with 1 DLL which I saw still uses Vulcan DLL's. But that DLL is not included.


I tried DependencyWalker but this has not been updated for years and only produces unusable output and a GitHub project I found (https://github.com/lucasg/Dependencies) doesn't work either.

What could cause this or how can I check?



Dick

Dick,
Dependency walker does not find Dotnet dependencies.
To check these open the assemblies with ILSpy.
I suspect that WCFInterfaces is an assembly that you created yourself and that this assembly has a reference to Vulcan.
Maybe not on purpose, but if you compiled this assembly with Vulcan or X# in the Vulcan dialect then some attributes may have been added to the assembly that require the Vulcan assemblies to be there.
To avoid that recompile that assembly in the X# Core dialect and simply remove the references to the Vulcan DLLs.

Robert

I hardly dare to to write this....

I didn't replace that exe in my production environment - and was still using the old one based on Vulcan there, assuming I was using the new one based on X#. Sorry!

But my question learned me that ILSpy is also suitable as a .Net "DependencyWalker" Thanks for that (too)!

Dick

Hey Dick, this is great... you didn't blame VS.

We're making progress B) B)

Nick

Dick,

ic2 wrote:I hardly dare to to write this....

I didn't replace that exe in my production environment - and was still using the old one based on Vulcan there, assuming I was using the new one based on X#. Sorry!

But my question learned me that ILSpy is also suitable as a .Net "DependencyWalker" Thanks for that (too)!

Dick

That has happened to all of us.
The solution: give your assemblies assembly version numbers and increment this version when you do a breaking change (like switching the runtime).

Robert

Hello Nick,

NickFriend wrote:Hey Dick, this is great... you didn't blame VS.
We're making progress B) B)

Of course I tried but I couldn't possibly think of anything. Normally it is a lot easier to blame VS as VS normally is to blame :silly:

Dick