VB.NET project won't compile when converted to Mercury

Elements Mercury
1

I decided to see how well some of my existing projects do if I try to convert them to Mercury. This simple project basically has a single code file with various enums defined that are used by other projects in the solution. For some reason, Mercury will not compile this project - it is generating errors in “My Project-Settings.Designer.pas”, like so:

image
image1178×247 20.8 KB

I’m attaching the project - hopefully you will be able to see why Mercury isn’t handling this project well.
Kandor.Types.zip (42.8 KB)

Note: This is in Visual Studio 2019, Elements 10.0.2597. Still experimenting - so not an emergency.

–Avonelle

2

Some additional information…

I opened the project in Water and it compiled without issue.

Now I have opened the project again in Visual Studio 2019 and it is compiling fine. Water seems to have “fixed” it.

Doing a comparison between the files I sent you and the folder that contains the fixed project, I see these differences:

In the Kandor.Types.elements file, the old project did not include this section, but the fixed version does:

<Compile Include="My Project\Settings.Designer.vb">
  <DependentUpon>My Project\Settings.settings</DependentUpon>
</Compile>

Also the Settings.Designer.vb file is different. Here’s a screenshot of the diff (the file on the left is the broken one, and the file on the right is the fixed version):

Settings.Designer.vb.Comparison
Settings.Designer.vb.Comparison2117×1158 123 KB

I hope this is helpful. I’ll see what else I run into as I switch the remaining projects in this solution to Mercury.

–Avonelle

3

Good catch. it seems the lack of RootNamespace generates bad code in the .Designer file. fixing now.

Workaround: set a Root namespace, then it compiles fine for me.

Curious.

Hmm., the import should remove this (as we’re now generating Settings.Deisgner at compile-trime, same as Resources.Designer); there’s no way Water would add this back, so something else must be going on here.

Curious. Water would not update these on its own…

4

Fixed.

5

Hmmm…I assume then that Visual Studio did it. I wonder if it would be worth it for me to start over with the code from the beginning, and look at each file more carefully as I do things, to see where things happened. Would that be useful, or does it not matter from your perspective since you know it isn’t Water?

–Avonelle

6

Can’t hurt, jic.

7

Ugh - apparently this solution is not under source control. :frowning:

I can obviously go back to the vbproj files instead of the *.elements file, but since the .Designer files also changed I can’t easily return back to that. Sorry.

But at least I know now, so I will get it hooked into source control as I look at the other projects in the solution.

–Avonelle

8

:frowning: sorry to hear that.

9

I found old copies of those files designer files, and tried to replicate what happened before (after putting things under source control).

And I can’t.

In fact, I’m pretty much getting the same compile errors in both VS2019 and Water now, which I guess is good from a consistency standpoint.

So I don’t know why things suddenly started working last time, and why I can’t get that behavior this time.

But in the end, if the compiler is able to handle that issue with the lack of a RootNamespace in the .Designer file, I’m sure it will be fine. And as you pointed out - setting a Root namespace solves it.

Thanks,

–Avonelle

10

Yeah, thats already fixed.

very odd indeed.if somehow the file got added back to the project that would explain it (the build only generates Settings.Designer.pas on its own, if it’s not present; if it is, that one is used, instead.

11

Could be. As I go through the process of migrating the rest of this solution, I’ll try to watch things a bit more carefully so I can provide more useful feedback.

–Avonelle

1 Like