There is a mismatch error - with x86 on - more trouble with VS

[ic2]

This is actually a copy from what I posted in the NG, Chris' reaction (as always very fast) and what happened then in VS.

I get this error:

C:Program Files
(x86)MSBuild14.0binMicrosoft.Common.CurrentVersion.targets(1820,5):
warning MSB3270: There was a mismatch between the processor
architecture of the project being built "MSIL" and the processor
architecture of the reference "VulcanDBFCDX, Version=4.0.401.0,
Culture=neutral, PublicKeyToken=0e73a8bf006af00c", "x86". This
mismatch may cause runtime failures. Please consider changing the
targeted processor architecture of your project through the
Configuration Manager so as to align the processor architectures
between your project and references, or take a dependency on
references with a processor architecture that matches the targeted
processor architecture of your project.

In earlier cases, with this error, I could go to Project Properties,
select the Build tab to the left and then set the "Platform Target"
option to the right to x86.

Which I did in this project. But this error seems to be related to the
Vulcan DLL.

I have created a reference to Vulcan 4 libs but the same happens when
I would select Vulcan 3 libs.

How can this be solved?

=========================================================
Chris replied:
>Hi Dick,
>
>Yes, the message is related to the platform target, I suspect you have
>set it to x86 for the Debug configuration, but you are building in
>Release configuration, or the opposite. Just make sure you have both set
>to x86 and the message will go away.


My reply

This is one of the reasons I hate VS. In the toolbar above my project I can select Debug /x86 and Release/x86, from a listview. I did do that already (x86).

I can also select Configuration Manager which opens the same windows as when you select Properties from the Solution. There it still says Any CPU. Why, I wonder...Ok, I change that to Platform Active(x86) but in Configuration Properties it still says Any CPU for the 3 projects in my solution. Why, I wonder for the 2nd time. But I can edit that although x86 is not part of the options. I have to click New from the listbox where it also shows Any CPU and Edit. I click New and now I can select x86 from the listbox New platform. And also Copy settings from Any CPU.

I of course have no idea what I am doing.

I can repeat that trick twice but for the 3rd project (a C# project but that may be because it's just the 3rd project in the list) in the solution I get the following error:

This platform could not be created because a solution platform of the same name already exists.

So I leave the C# project in the solution in the Cofiguration Manager on Any CPU. At this moment the first project, also a C# project shows x86. The X# project shows Any CPU and I change that form the list box. I click Apply. I do the same for the Release configuration. I go back to the debug configuration. The just changed project shows Any CPU, only the first shows x86. I enter x86. It doesn't stay that way.

I rebuilt the solution. Now I get 18 errors starting with

Severity Code Description Project File Line Suppression State
Error XS0006 Metadata file 'D:XSharpProjectsIC2ExtLibForVOIC2CSMethodsbinx86DebugIC2CSMethods.dll' could not be found IC2ExtLibForVO XSC 1


for the CSharp project which I changed. Plus a lot of The tpe or namespace can not be found errors. VS has no clue anymore of what is in the solution.

Clean solution does not help. Put back everything to Any CPU. Clean. Restart. The 18 errors remain. No idea why.


Did I tell you I hate VS?

I think I have to start over from scratch and copy code; this is usually quicker than trying to solve a VS problem.

Hopefully the then restored project works without x86 set because trying to change anything except (most of the times it is) only code in VS is more devastating to a VS project integrity than anything you could think of in VO 1.0. Or most likely: I think the alpha version of VO 1.0 was more stable than any VS version.

Did I tell you I hate VS?

Oh yes, I did ...


Dick

[Chris]

Hi Dick,

Hmm, maybe this reply of mine doesn't sound clear, but I replied to another post of yours in the newsgroups and my suggestion was to set the x86 option in the project properties, for the configuration you are using. I know this is confusing as well, so in short:

1. Restore back your original solution or restart from scratch
2. Open the project properties of your library (right click on the project item in the Solution Explorer)
3. Go to the tab page and set the Platform Target to x86.
4. In the "configuration" combo on top (but inside the project properties "window"), select also the "other" configuration (if it says "Debug" then select "Release" and vice versa) and set again the Platform Target to x86. Save and close the project properties.
5. Don't worry about what the toolbar says about AnyCPU, you have now set compilation to be done in 2bit mode. Just build your project and the messages should go away.

Chris

[ic2]

Hello Chris,

I've followed the steps exactly. First I removed all the Vulcan references and added only VulcanRT and VulcanRTFuncs, to be sure those from the Vulcan 3 Redist directory.

Then for all 3 (1 X#, 2 C#) projects in the solution, I selected rights mouse, Properties, went to Build and changed the Platform Target to x86. I did so for Active (Debug), Release, Debug and All configurations. In the picture one of the 12 property screens I changed & checked:

Alltox86.JPG (31.75 KiB) Viewed 687 times

I did not touch as you wrote the 2nd combobox saying Any CPU (as adding x86 and selecting that makes the metadata to my 1st C# project unavailable). Restarted VS, checked all 3 x 4 settings again (still all x86), Clean solution, Rebuild.

Below is the result. So still a mismatch for the 2 DLL's of the project (set to x86) and 1 of the 2 Vulcan DLL's, the VulcanRTFuncs.

I've also created the DLL in Release mode and copied all the file in the binrelease directory and still the VO Finit() fails - probably because of this error.

So I am actually stuck. Did I miss something? All done in VS 2015 but we started the project on a VS 2017.

I mailed you the full project, before the above steps. Could you perhaps see if it works for you?

Dick

3>C:Program Files (x86)MSBuild14.0binMicrosoft.Common.CurrentVersion.targets(1820,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "D:XSharpProjectsIC2ExtLibForVOIC2CSMethodsbinDebugIC2CSMethods.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
3>C:Program Files (x86)MSBuild14.0binMicrosoft.Common.CurrentVersion.targets(1820,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "D:XSharpProjectsIC2ExtLibForVOinterfacesbinDebuginterfaces.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
3>C:Program Files (x86)MSBuild14.0binMicrosoft.Common.CurrentVersion.targets(1820,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "VulcanRTFuncs, Version=3.0.303.0, Culture=neutral, PublicKeyToken=0e73a8bf006af00c", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

[Chris]

Hi Dick,

Sorry, I had missed the (link to) attachment in your message. I downloaded now and I indeed see the problem. Hard to say what's causing this, will ask the VS experts and will get back to you about this!

Chris

[ic2]

Hi Chris,

Great to hear that you can see the problem yourself. Your help is much appreciated. Moving this library from Vulcan to X# is an important step for us to get committed to X#.

I am quite convinced that it's something caused by VS. I spend lots of time with obscure command line programs with lots of parameters solving one or another VS problem (usually at least) but here I couldn't find one yet.

Dick

[robert]

Dick,

I have been thinking about writing a blog article (more likely 2 or 3) about the build process inside and outside Visual Studio and the "mysteries" inside the project files.

Your struggle has convinced me that I really have to do this.

I will have a look at your project files to see what the problem is.

Before I do I want to explain one thing that adds to the confusion:

One of the confusing things is most likely the difference between the Platform that you see on the toolbar inside VS and the platform that you define on the build properties page in your project properties.
These are 2 different things and should not be confused.

On the Toolbar inside VS you see 2 comboboxes:
1) Configuration (Debug / Release)
2) Platform (AnyCpu)
The values behind these comboboxes can be managed from the Configuration Manager inside VS.
The different combinations are stored in the Solution File.
You can define any platform and any configuration that you want !
When you create a new project we have defaulted to the values that most people are using.

Inside the XsProj files (but also VnProj and CsProj etc) there are sections with conditions.
The contents of these sections will only be included in the build process when the Configuration and Platform values in the conditions match the values on the VS toolbar.

The platform on the Build page is a variable (inside MsBuild it is called a Property) that is send to the build system. This variable controls the commandline that is created to call the X# compiler. This platform is either x86, x64, Arm or AnyCpu. These values match the commandline parameter /platform of the compiler (see https://www.xsharp.eu/help/opt-platform.html)

I will try to write the first article about this next week when I am in Seattle.

Robert

[ic2]

Hello Robert,

The article would be great. It is indeed confusing. I now try to understand what you already wrote

Apart from the persistent mismatch despite x86 being set error Chris could reproduce, it would be useful to see why the procedure I earlier wrote on the NG lead to an irrecoverable unusable project.

For now, it's a bit of a show stopper as we can't use the X# DLL from VO so I hope you can find a cause for it.

Dick

[NickFriend]

Dick/Chris,

I've just started my first foray into XSharp - I need to add some functionality to a C# project to read data out of some very strangely configured DBF files.

I've created an XSharp project within my solution, and added the required Vulcan dlls as references (Version 3 from the current trial download), and I get the same error as Dick. What seems to happen is that when you change the target in the XSharp project properties window, the change doesn't get saved to the project file (stays saying AnyCPU for both Debug and Release).

However this is a warning message not an error, so in fact I can continue working and the compiled application works correctly - the XSharp assembly is correctly called from my C# assemblies and I can read DBF files in VO style.

So there does seem to be something wrong, the target is not set correctly, but it's not a show-stopper as the application does potentially work... at least while Chris looks for the source of the problem.

Nick

[robert]

Dick,

I have found the problem and a relatively easy solution.
And to start : it is not as Microsoft problem but a X# problem:
If you open your xsproj file with a text editor you will see that it contains 5 propertygroups. The first propertygroup has no condition, the others have a condition.
When writing changed values from the project properties screen we try to locate the section where the values need to be written.
For properties that are not configuration dependent that is not a problem. They goto the first group.
For properties that are configuration dependent we are locating the correct projectgroup by looking at the condition. And there is the problem.
The condition for the first debug configuration is :

Code: Select all

"'$(Configuration)|$(Platform)'=='Debug|AnyCPU'"

The condition for the other debug configuration is:

Code: Select all

"'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'"

If you look closely you will see that the second condition has spaces around the "==" operator.
And that is exactly what the project system is looking for when writing changes from the project properties dialog.

As a result the new values from the properties dialog are written to the 4th and 5th groups, which is not where they belong.
You can fix this your self by making the following changes:
- add the missing spaces around the "==" sign in the conditions for the 2nd and 3rd projectgroups
- move the properties from the 4th and 5th groups to the 2nd and 3rd group with the exception of the prebuild, postbuild and runpostbuild properties.

Then open the project in VS again and adjust the project properties when needed.
If you have added the spaces around the condition correctly then it should work.
Al new configuration dependent properties should be written to groups 2 and 3.
Only the build events goto the 4th and 5th group.
The "why" of these different groups is something that I will discuss in my article about MsBuild and the project file format next week.

Robert

PS: We will change the project system, the templates and the converters to make sure this will be automatically fixed in the next build. Until then you should check this yourself.