Error XS0006 Metadata file could not be found

[Chris]

Hi Dick,

No, you cannot use PARTIAL in order to spread methods of the same class in different libraries/aefs in .Net. There is absolutely no way to do this, period.

But of course it is not "absolutely impossible" to refactor your code, so this is not needed anymore. A lot of VO apps had been using this feature, but it was not a very big deal changing them, so there are no external methods anymore. If you'd like, you can send me the aefs of your app and I will suggest you ways how to do it.

[FFF]

No, you cannot use PARTIAL in order to spread methods of the same class in different libraries/aefs in .Net. There is absolutely no way to do this, period.

Useful thread. Had no clear idea about this, so googled https://docs.microsoft.com/de-de/dotnet ... nd-methods and found "Alle deeltypedefinities die bedoeld zijn als onderdelen van hetzelfde type moeten in dezelfde assemblage en module (EXE- of DLL-bestand) worden gedefinieerd. Gedeeltelijke definities kunnen niet meerdere modules omvatten".

[ic2]

Hello Chris,

I think refactoring resulting all code of one class in 1 project is not an option. Thanks for your offer but my guess is it would take months to 'refactor'. The ReturnADS method is such a sample which I can not move to IC2DBServer without losing access to general function in the IC2.lib. And I can not move the IC2DBServer to IC2.lib without compromising projects which do include IC2DBServer but do not use IC2.lib but other libs included, using partly the same methods but with a different working.

This may sound strange but for one of our clients part of the existing libs have been developed differently, departed from what we do here while other libs haven't. We could never get these together unless we check and where needed rename 1000's of methods and calls. In VO I can easily include a couple of common libs, exclude some "same but different" libs and maintain code in only one place.

The only other way to 'refactor' is to merge everything and I am not prepared to do that. If that is indeed the only solution I will keep my main projects in VO. For all those years I have been working in .Net and VS it always seems the same, compared to VO: somewhere you go one step forward and then you stumble across something which is 10 steps backward.

Apparently I misunderstand PARTIAL CLASSES and thought they could work over multiple projects instead of only over multiple files. However, this guy had about the same question :

https://stackoverflow.com/questions/309 ... s-projects

and one of the replies was:

Using Visual Studio 2015 and later it is possible to split partial classes across projects: use shared projects (see also this MSDN blog).


Not sure if this is going to be a solution. I will have to read more about it.

Dick

[wriedmann]

Hi Dick,
What you can do (and what I'm doing also in VO) is to include one prg file in more projects.
Wolfgang

[robert]

Dick,

,

Using Visual Studio 2015 and later it is possible to split partial classes across projects: use shared projects (see also this MSDN blog).

We are not supporting shared projects in our project system.
But like Wolfgang said: you can share files between projects. To do so in VS, add an existing file and make sure you press the arrow button next to the [Add button] and choose "Add as Link"

addaslink.png (1.29 KiB) Viewed 388 times

Your file will then show with a link overlay in the VS Solution Explorer

linked.png (2.15 KiB) Viewed 388 times

Robert

[Chris]

But again, this is not about extending a class with new methods in different libraries, without merging them. Dick, especially with the ReturnADS() method, this is absolutely no problem at all, because all it does is to call one function and return its value, it's less that 10 minutes total refactoring this to work without issues in .Net. I am sure also all the other cases will not be a problem at all really. I can bet you on that, but if you are determined and decided already that it is not possible, then we cannot help you, maybe then it is indeed better to keep your apps in VO.

[ic2]

Hello Robert, Wolfgang,

Pointing to prg's which were originally neatly separated has the following disadvantages:

1 Source control won't work. I have never seen a good working source control anyway, but from what I tried with Bitbucket, a year or more ago, I know that changing a .prg does not trigger the source control to mark all projects where this prg is used as changed. Only the project from where I edit the .prg.

2 It goes against everything we have learned for years about designing for re-usability of code. Even if this is not literally broken, with including prg's, it means visually that you get one large project.

I will continue to work on the conversion as I do now, as it definitely improves & prepares my VO code but a very likely outcome I foresee now that it will stop there for me. Better a good structured VO project, where almost everything in the IDE works better than in VS anyway, than moving to a .Net project which needs a bag of tricks otherwise it won't work. I will occasionally add a C#/X# method to my existing lib, used from VO and we have a few smaller projects which do not use these libraries. These can be converted.

Thanks anyway for all the explanations.

Dick

[wriedmann]

Hi Dick,
sorry, but I cannot understand one thing: you don't like Visual Studio, but you don't change to XIDE (and I can confirm that XIDE works better than the VO IDE).
Why you don't use XIDE for your migrated applications, and Visual Studio for your new WPF development?
Maybe we can build a tool that keeps XIDE and VS project files synchronized...
(as it looks now, we here in Italy and maybe the rest of the world will have plenty of time to work at home for the next months when nearly all companies need to close their offices).
Wolfgang

[ic2]

Hello Wolfgang,

I've got a number of reasons to keep using VS (leave it to me to keep you occupied in this , hopefully limited period of isolation)

1 You already mentioned WPF. If I proceed with bringing my main projects to X# (this has become less certain now with the latest information) I would directly want to create new windows in WPF.

2 My main issue with .Net programming against VO programming is the impossibility to sort on and edit individual entities or quickly set or unset a couple of entities to Debug. That won't work in any .Net editor.

I checked a couple of other things which I dislike in VS, but this is not in Xide either. Like that in the error messages nor VS neither Xide mention in which method the error is (only the whole program). In VO I can often quickly asses where the problem comes from when I get a bunch of errors; in VS or Xide I have to open each individual error to find that out.

3 I am used to VS now. I will have to get used to Xide for a while, but that doesn't make sense (see 1). And the (few) things I like better in VS than in VO are, as far as I know, not in Xide (yet), like Peek Definition, filtering on errors (which is actually quite handy with the conversion), Code Lens. Although also not yet implemented in VS for X# either, but it does work for C# code and probably Amdisense is doing that job in Xide but I could not get it to do something actually.

What do you consider the main advantages for Xide against VS?

What I like more in Xide:
1 Ctrl B is a toggle to comment out code, like in VO, while in VS it's Ctrl Alt something and Ctrl Shift Alt Something else both followed by a second key. Or something like that, in any case something which you can not recall so end up typing manually.
2 Second is that there is View/No split, horizontal/vertical. Easier than in VS, but VO is still better because it has 2 icons for it and you can combine horizontal and vertical.

Dick

Dick

[wriedmann]

Hi Dick,
first of all, XIDE is ways faster than VS, and then it is source code oriented like VO (the only painter I use in VO is the Window Editor - no other one).
And I like the fact that it has a cleaner GUI than VS - and the possibility to export/import applications and entire projects.
When it comes to WPF, I prefer the code based approach because WPF is so dynamic that I need full control over all properties (and full oversight!).
Wolfgang