Error XS0006 Metadata file could not be found

[ic2]

Hello,

The AEF I am converting from VO had list of errors and warnings for which I have to find a solution. But this morning the only error it shows is:

Error XS0006 Metadata file 'C:XporterOutputDebugACE.dll' could not be found

There is no ACE.dll anywhere in the project (Ace32.dll is one of the ADS DLL's though).

Where does this error come from and how can it be solved?

EDIT:
In my notes I found: DLL mentioned in error is not created because of other errors. Solve these first

But this gives me 2 problems. One is: where does this non existing metadata file referene come from? Second is: how could I get rid of this error and work on the other errors, because these do not show anymore!

Dick

[Chris]

Hi Dick,

This means that this dll is used as a reference by your app/project, but this dll has not been compiled yet, so it does not exist. But in this specific case, you do not need this dll, its specific functionality has been implemented inside the X# runtime, so it's as simple as removing this from the references.

[robert]

Dick,

With X# 2.3a you should not have to import the ace.aef or dbfaxs.aef from VO.
Simply add a reference to XSharp.RDD to your project. All function from these 2 aefs are inside XSharp.RDD already.
Also the class AdsSqlServer is included. I am not sure if AdsDBServer is included and/or needed. I will check.

Robert

[ic2]

Thanks Robert & Chris, removing ACE (not tne name of the DLL but indeed the name AEF included) helped. Next Metadeta issue is a missing bBrowserClasses.dll, this requires other action. I have removed all references with an icon behind it that it is missing and only now I am back to my original errors.

The main thing which surprised me is that until one day back I was working on all kind of "tangible" error messages while suddenly this error comes up and no other error remains to be checked.

I am still working out a strategy. Currently it looks as follows:

1 Make as many changes in the VO program as possible which prevents the error (on re-"porting") in X#

2 Get rid of all these generated _external_class additions. This is a lot of work, as I have to do it manually one by one, find the END CLASS and every time I have to recompile due to the terrible structure in Visual Studio with all code in 1 .prg.

Hence this question: when was this _external_class addition introduced? I think I can proceed a lot faster if I install an old X# (just for xPorter) which does not create this code.

As written, it is much faster to add 'dummy' classes and methods (even if I have to do that manually). The program would compile as the missing classes "are present" and I can easily remove them later when the AEF's where the classes are present are also converted, and included.

3 Try to prepare replacement methods for AEF's (like generated Excel, Word code etc) which won't work like that in X#/.Net. Ideally, I would like to have this newly generated code ready for use on a later import with only minor adjustments to the calling methods. Not sure this is the case

So my strategy is to have each individual XPorted AEF error free (I realize that this differs from 'working') as fast as possible. As much as I understand the logic behind the _external_class generations I really feel this stalls my objective as explained above very much. Hence it would be great if you could point me to an X# version where this is not generated. I could not find it in the WhatsNew.
Maybe in the end I will have to review the strategy anyway but for now I want to try if it works.

Dick

[Chris]

Hi Dick,

I am probably not explaining it well, but the whole issue with that external class thing, is that you have created methods for a class that is not defined (the class itself) in the same .aef. This by itself is not allowed and was never allowed in .Net and also X# of course.

All that VOXporter does is that it tells you about it, it only surrounds the method with a CLASS...END CLASS, so you know about this, that this is not becoming a part of the class you wanted to, as you did in VO. The alternative would be to just completely delete this method from your code, but I am sure it is much better leaving there and notifying you about it.

[wriedmann]

Hi Dick,
only a suggestion: I have moved these added methods to a separate VO module, and the relative conterpart to a separate X# prg file.
When xporting again, I don't overwrite the project files, but only the PRG files, so the X# library remains intact and I don't have to make the same changes again and again.
This is my VO view:

vo_view.png (22.07 KiB) Viewed 703 times

and this the X# side (XIDE in my case):

xs_view.png (178.65 KiB) Viewed 703 times

Wolfgang

[ic2]

Hello Chris, Wolfgang,

I may well have misunderstood something but what I see as heaps of _external_class ...endclass statement which were obviously not in the converted VO codeand which I also do not want in my X# code because eventually the X# libraries will be included all together in the several projects where the mow "missing" classes will be present.

Due to the nature of VS it is a lot of work to remove them all. In VO I could have deleted them straight from the LV of entities in minutes. In VS I have to remove the _external_class by double clicking the first error and then delete, search for the END CLASS, delete that, save, recompile (because the line number of the next error is no longer valid) and start all over again. With the added chance that I delete END CLASSES which I should not have....

So would you happen to know if I can use an older X# version which does not add these _external_class statements (but simply give me only the compiler errors that the class is missing) that would save lots of time. After I have created the 'missing' classes .prg everywhere in a faster way I can switch back to the latest X# XPorter again.

So I would then do indeed what Wolfgang suggests: add the classes in a separate .PRG, compiler happy, I can focus on solving the real issues while knowing it won't work until the AEF is re-united with the other separately converted AEF's after which I can delete the temporary program

This would work way faster. Unless I misunderstood something....

Dick

[wriedmann]

Hi Dick,

you don't need to delete or unite anything.
Keep you VO source as it is, with the not-portable code in one module of your library.
Then your code will continue to work.
In the X# version, the first time you do the migration, simply delete the compatibility prg file that will not work, and add a new one with a different name where you can put the X# specific code - and your X# code will work .
When you in a later moment redo your migration, all your VO code will be happily ported, and if you don't let VOXPorter overwrite your solution and projects files, the existent prg files will be overwritten, but the X# compatibility file will remain as it has no conterpart in the VO library. The code of your VO compatibility module will be ported again, but since it is not a part of your application/library, it will remain there and not be compiled.

I'm doing that for several years now - and my library is modified always on the VO side, and then ported to X#, and I don't have to change any code on the X# side anymore (even if I have to do bugfixes on the X# side, I do them also on the VO side).

Wolfgang

[ic2]

Hello WOlfgang,

Hi Dick,

you don't need to delete or unite anything.
In the X# version, the first time you do the migration, simply delete the compatibility prg file that will not work,

Thanks for your time to explain but the problem is: there is no compatibility file. Currently all the unwanted external_class statements are scattered throughout 16 converted .prg files, in other words, this has been added to my VO code. And it causes heaps of compiler errors.

As far as I can see there are only 2 solutions to enable me to concentrate on solving 'real' errors: either I am going to remove this all (which I think is too much work) or redo the conversion with an old XPorter which does not add this unwanted code. Or maybe there are 3 solutions:

If you get all this code in a separate program you must be doing something different than I do. But what?

Dick

[wriedmann]

Hi Dick,
it is really simple: I have moved all this code to one module on the VO side.
In VO it is perfectly legal to distribute code of a class to different modules - so this is the best solution I have found.
I have done that also in the migration from VO 2.7 to 2.8 when the development team changed some prototypes of the ListView class.
Wolfgang