Quickest way to list all classes used per library

[ic2]

During many years we have come to a structure of libraries in all our VO projects. VO allows methods of one class to reside in multiple libs (only real limitation is strong typing).

I've been working om converting lib by lib to X# and then found out that this won't work as .Net does not allow that (not even with partial classes as I thought). According to Chris I have to rearrange my VO code such that no method of one class is found in multiple libs.

That is far from easy as I already suspected. I would like to investigate if it can be achieved at all or I should give up X# converting. A good starting point would be an overview of all classes used in a library so I can cross check which items need to be moved, and if that is possible at all.

This is not something available in VOPP I saw. Does anybody know a way to get this quickly (without sorting on classes and collect this mef by mef)?

Dick

[lumberjack]

Hi Dick,

Not going to comment on all you said, but want to highlight the following:

I've been working om converting lib by lib to X# and then found out that this won't work as .Net does not allow that (not even with partial classes as I thought). According to Chris I have to rearrange my VO code such that no method of one class is found in multiple libs.

Lets assume you have some code that is shared in multiple libs. Two options:

Opton 1:

Create your partial class code in a SharedFolderSomeSharedCode.PRG, then instead of new, Insert existing file in the Assembly, but don't duplicate it when asked if it should be copied into the project folder.

Option 2:

Code: Select all

// SharedFolderHelloWorld.prg
METHOD HelloWord() AS VOID
  ? "Hello world"
RETURN
//End of HelloWorld.prg

//MyClassNeedHelloWorld.prg
CLASS MyClass
  CONSTRUCTOR()
    SUPER()
  RETURN

//Here is the trick:
#include "SharedFolderHelloWorld.prg

END CLASS

HTH,

[Chris]

Hi Dick,

It is not necessary to adjust your code in the VO side, you can also do it in the X# version only. .Net has numerous very powerful features (delegates, events etc), which can be used to implement things in a much better way than in VO, without the need to use things like declaring methods of one class in multiple dlls.

If you give us some detailed info about your structure of your classes/dlls that have those external methods, I am sure we can suggest some ways to adjust your code in X# without requiring a lot of changes.

[ic2]

Hello Johan, Chris,

Thanks for your comments.

@Johan: The problem is not the use of classes from another library, the problem is that I have Method HelloWorld Class Communication in lib 1 and Method HelloSouthAfrica Class Communication in lib . Works in VO, not in .Net, also not with partial classes (what I thought).

In some cases there is probably no good reason (anymore) for not having these 2 methods in more than 1 lib. For some there probably is, and in the most ideal case, I can eliminate this "multi lib' methods completely by moving so I can proceed to the next step.

@Chris: Our 2 main projects are huge and maintained on daily basis. There is no way, especially for the project of Mariette, that they can stop making changes in the VO program to start finding out how to get things working in X#. That's why I want to prepare library by library in VO. This way, I would have far less changes to make and I want to end up with a "blueprint" of what to do after converting, which is e.g. replacing Office and other OLE access code, and some other VO code which won't work in X# at all.

If I can map the classes ("where is what"), move as much as possible (in VO) I eventually hope to create a error free X# end project (compiler wise) relatively quickly.

I don't know anything about delegates and events (probably don't want to know ) and I certainly don't want to add extra time to the conversion process (for the above mentioned reason) by trying to understand how these work and how I should implement this in my X# program.

So bottom line is: we understand that the conversion will cost time. But if we can't find a way to prepare most work in VO and have a nearly 100% VO program in X# relatively quickly, conversion is simply a no go.

We are aware of better features in .Net (although some features often just mean more typing work without any advantages, like interfaces) or less control in the process (like For..Each in most cases), that's one reason we want to move eventually, but the first step *must* be a VO version with little trouble in X#.

Dick

[Chris]

Hi Dick,

To give you an example, I know from previous conversations, that yo have at least this:

Library1:
CLASS ClassInLib1

Library2:
FUNCTION FuncInLibrary2()
// do work...
METHOD MethodInLib2() CLASS ClassInLib1
RETURN FuncInLibrary2()

so you cannot move MethodInLib2() to Library 1, because it uses a function from Library2. This code can be rewritten in X# as:

Library1:
GLOBAL FuncToCall AS DELEGATE // well, more or less

CLASS ClassInLib1

METHOD MethodInLib2() CLASS ClassInLib1
RETURN FuncToCall:Invoke()


Library2:
FUNCTION FuncInLibrary2()
// do work...

PROC InitializeFunc() _INIT1
FuncToCall := FuncInLibrary2


and this way you can move the method to the other library without problems and there is absolutely no other change you will need to make in your code, apart from the above. (it is pseudo-code mainly, the details of teh delegate depend on the parameters of return type of your function).

The above can be modified in your X# code in less than 5 minutes...Similarly many other cases can be talked, either this way, or by using inheritance, or with extension methods, or with something else, in most cases it will be easy, without touching your code in the VO side at all. Of course, if you have decided to do it purely in VO first, then this is the best solution. It will just be more time consuming.

[ic2]

Hello Chris,

Sounds interesting and I will make a note of it for my project. Is Invoke something like the .Net version of Send(#xx) in VO? That has been very useful but it also clutters the way the program works I must admit. E.g. if I change the method, the compiler won't protest on calls of this method from Send.

Still I would prefer to do as much as possible in VO, to minimize time to get things working like you describe. Even if the change would take me also 5 minutes (which I doubt :unsure: ) then it could take a lot longer if I have many of these changes to implement

I may have found a way to find these classes with methods in >1 lib I think. I have XPorted a complete project, with all libraries. I think sorting on XS016 :


Error XS9016 Class name IC2dbserver for method differs from parent class name IC2dbserver_external_class
should probably point me to all "lost" methods so I can see how many of these I can move without errors or loss of functionality in VO. Let's first check that.

Dick

[Chris]

Hi Dick,

It's sort of like Send(), put it is strongly typed, so if you change the method, the compiler will complain indeed.