.NET Any CPU targets

591 views
Skip to first unread message

Michael Powell

unread,
Jun 25, 2015, 1:47:45 PM6/25/15
to or-tools...@googlegroups.com
Hello,

I've got an issue, that is, I have a C# assembly which adapts Google OR-tools for use in a .NET solution. The problem is, at the moment of adaptation, I do not want to commit the CPU one way or another, so I leave it "Any CPU".

However, I get compiler errors such as here, which lead me to believe hat OR tools is 64-bit only?

1>  Restoring NuGet packages...
1>  To prevent NuGet from downloading packages during build, open the Visual Studio Options dialog, click on the Package Manager node and uncheck 'Allow NuGet to download missing packages'.
1>  All packages listed in packages.config are already installed.
1>C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "Google.OrTools, Version=1.0.3854.2335, Culture=neutral, processorArchitecture=AMD64", "AMD64". 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.
1>  Football.Constraints.Core -> I:\Source\Kingdom Software\Football\Simulator\Football.Constraints.Core\bin\Debug\Football.Constraints.Core.dll

Is this correct? How can we know this is AMD64, at any level? How can I target "Any CPU", which doesn't get constrained until a service, executable, or otherwise, target environment, unit test, etc, is discovered.

Would you mind clarifying? Or is this something that can be patched about the Google OR tools .NET build?

Thank you...

Best regards,

Michael Powell

Laurent Perron

unread,
Jun 27, 2015, 11:55:38 AM6/27/15
to or-tools...@googlegroups.com
Hi Michael, 

on nuget, I only push the 64 bit version.
I actually do not know how to build a mixed 32/64 bit archive.

Thanks

--
You received this message because you are subscribed to the Google Groups "or-tools-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to or-tools-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Michael Powell

unread,
Jun 27, 2015, 12:19:43 PM6/27/15
to or-tools...@googlegroups.com
On Sat, Jun 27, 2015 at 11:55 AM, Laurent Perron
<laurent...@gmail.com> wrote:
> Hi Michael,
>
> on nuget, I only push the 64 bit version.
> I actually do not know how to build a mixed 32/64 bit archive.

I understand. Provided I can find a spare moment, I may have a look at
this and submit a PR.
> You received this message because you are subscribed to a topic in the
> Google Groups "or-tools-discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/or-tools-discuss/lqgvT3PmsPI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

Michael Powell

unread,
Jun 27, 2015, 12:53:07 PM6/27/15
to or-tools...@googlegroups.com
On Sat, Jun 27, 2015 at 12:19 PM, Michael Powell <mwpow...@gmail.com> wrote:
> On Sat, Jun 27, 2015 at 11:55 AM, Laurent Perron
> <laurent...@gmail.com> wrote:
>> Hi Michael,
>>
>> on nuget, I only push the 64 bit version.
>> I actually do not know how to build a mixed 32/64 bit archive.
>
> I understand. Provided I can find a spare moment, I may have a look at
> this and submit a PR.

Along which lines, I want to submit at least an issue against this.

Then if/when it should be a priority for me, I can follow up; or
likewise anyone else wanting to contribute.

I do not see that capability enabled on the Github site:
http://github.com/google/or-tools

Or have I just overlooked the issues area?

Thank you...

sebapiu

unread,
Jul 2, 2015, 11:12:03 AM7/2/15
to or-tools...@googlegroups.com
I overcame this problem by using the method described in the first answer of the question here: http://stackoverflow.com/questions/666799/embedding-unmanaged-dll-into-a-managed-c-sharp-dll

Basically I include both 32 and 64 bit dlls as resources, and extract one or the other to a templ place depending on the current architecture executing the code. 

Michael Powell

unread,
Jul 2, 2015, 11:25:05 AM7/2/15
to or-tools...@googlegroups.com
On Thu, Jul 2, 2015 at 11:12 AM, sebapiu <sebast...@gmail.com> wrote:
> I overcame this problem by using the method described in the first answer of
> the question here:
> http://stackoverflow.com/questions/666799/embedding-unmanaged-dll-into-a-managed-c-sharp-dll

I take this to mean they are being built? But not distributed via
NuGet. I want to say it might be a "simple" matter of NuSpec elements,
but I could be wrong about that; in fact scratching a bit deeper than
surface, I'm not sure NuGet quite has the discernment necessary to
know "what architecture is the project targeting", to include x86,
x64, or AnyCPU.

> Basically I include both 32 and 64 bit dlls as resources, and extract one or
> the other to a templ place depending on the current architecture executing
> the code.

Thanks for the heads up.
Reply all
Reply to author
Forward
0 new messages