Add .Net Standard 2.0 support to OR-Tools #668
Conversation
Mizux
added
Feature Request
makefiles/Makefile.dotnet.mk
Outdated
| DOTNET_EXECUTABLE := $(shell $(WHICH) dotnet.exe 2>nul) | ||
| else # UNIX | ||
| ifeq ($(PLATFORM),MACOSX) | ||
| DOTNET_EXECUTABLE := $(shell dirname ${DOTNET_INSTALL_PATH})$Sdotnet |
There was a problem hiding this comment.
not sure about this, once you have done your brew cask install dotnet-sdk, just restart your terminal and you'll have:
$ which dotnet
/usr/local/share/dotnet/dotnet
There was a problem hiding this comment.
Restart terminal from CI?
There was a problem hiding this comment.
rehash or hash -r (osx) should do the job
makefiles/Makefile.dotnet.mk
Outdated
| ifeq ($(PLATFORM),MACOSX) | ||
| DOTNET_EXECUTABLE := $(shell dirname ${DOTNET_INSTALL_PATH})$Sdotnet | ||
| else # LINUX | ||
| DOTNET_EXECUTABLE := $(shell which dotnet) |
makefiles/Makefile.dotnet.mk
Outdated
|
|
||
| .PHONY: dotnet # Build OrTools for .NET | ||
| dotnet: \ | ||
| clean_dotnet \ |
There was a problem hiding this comment.
not sure clean_dotnet is needed
make dotnet will always rebuild while other e.g. make cc will print target 'cc' up to date nothing to do
makefiles/Makefile.dotnet.mk
Outdated
|
|
||
| .PHONY: detect_dotnet # Show variables used to build dotnet OR-Tools. | ||
| detect_dotnet: | ||
| ifeq ($(SYSTEM),win) |
There was a problem hiding this comment.
remove if same commands on both branches
| HideSolutionNode = FALSE | ||
| EndGlobalSection | ||
| GlobalSection(ProjectConfigurationPlatforms) = postSolution | ||
| {AFA3F878-FB56-4314-B31E-3DA5583B548B}.Debug|Any CPU.ActiveCfg = Debug|Any CPU |
There was a problem hiding this comment.
Do we really need this magic "hash" ?
Is it univeral or dependent of your system (i.e. kind of watermarking)
There was a problem hiding this comment.
This hash is the project identifier. So long as projects are added using the toolchain, this shouldn't be a problem.
There was a problem hiding this comment.
ok found ! https://msdn.microsoft.com/en-us/library/bb165951.aspx
BTW Thanks for the explanation
|
So basically we remove the csharp/fsharp compiler to use dotnet sdk if I understand well. I'm not against this change/move but I think I would wait a little before merging it since it will need to update the "install from source" to be sync (e.g. remove all And I would like to play with it a little to see how does it works (and give usage feedback) before approval/merge. BTW good job ! Thanks again ! |
makefiles/Makefile.dotnet.mk
Outdated
| @@ -145,6 +145,11 @@ $(GEN_DIR)/com/google/ortools/sat/CpModel.g.cs: $(SRC_DIR)/ortools/sat/cp_model. | |||
| $(GEN_DIR)/com/google/ortools/sat/SatParameters.g.cs: $(SRC_DIR)/ortools/sat/sat_parameters.proto | |||
| $(PROTOBUF_DIR)/bin/protoc --proto_path=$(SRC_DIR) --csharp_out=$(GEN_DIR)$Scom$Sgoogle$Sortools$Ssat --csharp_opt=file_extension=.g.cs $(SRC_DIR)$Sortools$Ssat$Ssat_parameters.proto | |||
|
|
|||
| $(CLR_KEYFILE): | |||
| ifdef CLR_KEYFILE | |||
There was a problem hiding this comment.
swap both lines ?
if CLR_KEYFILE is not def is not necessary to create the rule : i.e. empty ?
|
@Mizux is there another fix in master branch to fix appveyor builds. |
|
Hi, didn't know master was broken, on my way to fix it. Sorry for the inconvenience, shame on me ! |
|
There is also an other error, the recent commit df333ef has reverted my patches i.e. protoc must use EDIT: fixed by b44277a |
|
@Mizux for the windows build does the |
Dynamic linking Windows Search Order:
src: https://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx?f=255&MSPPError=-2147217396
|
|
I'm looking forward to this. Sorting out some of my bits re: |
|
👍 This is awesome work. I look forward to giving it a look. Thanks! To be clear, one doesn't "target" .NET Standard, per se. From what I understand, Standard is to Core what PCL was to portable run times from prior years. Test assemblies, applications, etc, then target 4.6.1, Core, or other actual run time, and so on. However, if I understand it correctly, virtually every other constituent assembly up until the point of commitment could potentially target .NET Standard. I found this out somewhat to my chagrin porting one of my other suites to the .NET Standard paradigm. |
|
My understanding is in theory: Now on Nuget side taking a famous package https://www.nuget.org/packages/NUnit/ ,it says
What's puzzle me (I'm start to getting lost) is why it is listing .Net Standard 1.6+ here, actually it seems that .NetStandard is also a target platform. So inside the nunit.3.10.1.nupkg/lib you have:
My understanding concerning runtime is
My long term objective is to have net45 (or net46?) + netstandard2.0 dir in ortools nuget package. ToDo: (in an other repo? or in a test/project directory)
|
|
@Mizux That's along the same lines as my loose understanding. The trouble is, if it is an "API definition" or "API surface area", whatever you call it, then why offer it as target of any assembly project at all? That was, still somewhat is, part of my confusion. "It works", but I would still like to understand it a little better. It is closer to, say, compiled byte code in Java, ubiquitous, regardless of the JVM, or the PCL, "portable" class library. Actually PCL is in the history, maturity of how we've gotten here, apparently. |
|
As I said (cf link above) .Net Standard is both a "API surface area" and a "target platform" (kind of generic/universal/ubiquitous byte code that other .net implementation can consume if their are compatible with this standard). This also explain why people ship net45 and netstandard1.6 in the nuget package since .Net Framework 4.5.1 only support NetStandard up to 1.2 cf https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-implementation-support. @ALL Do you think also providing note: providing a nuget with a |
|
@Mizux The difference between .NET Standard and the target frameworks is not my understanding. Standard is closer to PCL than it is the run-time is my understanding. Folks ship both either because they are as royally confused about it as I am, or be cause truly their assemblies may make sense for maximum portability, and/or they also think their assemblies could stand alone, as a truly target run-time environment. One case in point is testability; test assemblies must target a run-time; NOT the Standard. I just got done with a round of these shenanigans, so I'm pretty well acquainted with the difference by now. |
|
@Mizux To answer your broader question, don't confuse Now, what that means for OR Tools... Depending what sort of features you want to leverage, could you target both? That would reach the broadest possible audience. That is, both As for earlier mentions of fails during test assemblies? Make sure you are targeting the run times, not the API targets. That is, |
|
Hi all, @acco32 @mwpowellhtx I continued some refactoring on dotnet which currently live on master... 52c126c 496be16 6cd212b 13b8633 d0c2e17 0f2980d Currently I'm verifying our docker distro can build master and create our usual working archives, once done, I'll test the Nuget generation... |
|
@Mizux I'm really interested to take a look at at least a solid prerelease RC package right now. If confidence is high this is on a winning track, then perhaps examples could be packaged separately from now on, i.e. |
|
Issue filed along these lines. If it can be easily addressed, awesome! Without distracting from the overall goal of this endeavor, that is. |
|
The installations for OR-Tools with .Net currently say the following: "Prerequisite: .NET Core 2.1 SDK Simply install this https://www.microsoft.com/net/download/thank-you/dotnet-sdk-2.1.302-windows-x64-installer" Does support for .NET Standard 2.0 mean that users could install .NET Standard instead of .NET Core? Would this be of interest to the ordinary OR-Tools user, who is not building applications? Thanks. |
|
@paultrow I do not know about OR Tools docs, but to be clear, as I understand it and has been explained to me, Standard is not Core, and Core is not Standard. Standard is an "API surface area" so to speak, whereas Core is a run-time. Standard dependencies are closer to PCL from previous years, and can be consumed by, i.e. are dependencies for, Core projects, .NET Framework 4.6, 4.7, depending on the Standard version, and so on. I don't know if this answers your question, but it's not as simple as "depending on Core". Extending the thought, however, in my mind, I would expect OR Tools itself to "target" (though, not in the traditional run-time sense) Standard, and not Core. Save the run-time targeting for the very last moment when the Tools package is consumed by the end product. |
|
@lperron What's the situation re: this effort? Where does the test code, samples, etc, stand? Let's separate those packages so we can see some measurable progress publishing at least an RC package for the OR Tools themselves, shall we? Thanks! |
|
@mwpowellhtx My main question is who among OR-Tools users is support for .NET Standard relevant to? I'm guessing that for the vast majority of users, it isn't important. |
|
@paultrow This conversation was had a couple of months ago, and the decision was to go with Standard. Did something change with respect to Standard, Core, etc, landscape in the meantime? Excuse me, sir, with all due respect, you're talking to one right now. For anyone else following the trajectory of the ASP.NET Core, .NET Standard, .NET Core landscape, it should matter, also. |
|
I apologize if I offended you. I'm simply gathering information for the OR-Tools Release Notes and installation instructions. I'll look elsewhere. |
|
@paultrow I don't know what your background is, your Github profile seems rather barren at the moment, for instance. Core/Standard is/was/continues to be confusing even for the "washed" so to speak, so the confusion is understandable. Personally, I've made an effort to get informed about it; for instance, .NET Foundation holds a weekly (for the most part) YouTube/Hangouts stand up that covers the latest goings on concerning ASP.NET Code, Standard, and Core timelines, etc. Gitter is also an interesting source to learn about discussions of this nature. I'm not sure what is meant by "ordinary OR Tools users" or "who is not building applications"? In what sense of the word "applications"? Desktop, web-based, component assemblies? At least from a .NET perspective, OR Tools is not an application unto itself, at least not as far as I am concerned. |
|
Oh, let's calm down :-)
Paul is our technical writer working on or-tools.
I decided we would offer a nuget package build with dotnet core 2.0.
From what I understand, it can be used by dotnet core directly (useful for
non windows users), or consumed by visual studio (latest vs2015 or 2017 if
I am not wrong).
We released a stable version in 6.8 that included lot of unbundling,
especially around all third parties we depend on.
Building the nuget package did not make the cut. but should be available in
August with v 6.9.
Did I miss something?
Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53
00
Le lun. 30 juil. 2018 à 08:15, Michael W Powell <notifications@github.com>
a écrit :
… @paultrow <https://github.com/paultrow> I don't know what your background
is, your Github profile seems rather barren at the moment, for instance.
Core/Standard is/was/continues to be confusing even for the "washed" so to
speak, so the confusion is understandable.
Personally, I've made an effort to get informed about it; for instance,
.NET Foundation holds a weekly (for the most part) YouTube/Hangouts stand
up that covers the latest goings on concerning ASP.NET Code, Standard,
and Core timelines, etc. Gitter is also an interesting source to learn
about discussions of this nature.
I'm not sure what is meant by "ordinary OR Tools users" or "who is not
building applications"? In what sense of the word "applications"? Desktop,
web-based, component assemblies? At least from a .NET perspective, OR Tools
is not an application unto itself, at least not as far as I am concerned.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#668 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKj17XfztJ0NRRvfnpwWMP2uLVrJIllxks5uLyMEgaJpZM4TjEOz>
.
|
|
".NET Standard 2.0" is basically a standard set of library APIs that you code to. If or-tools targets .NET Standard, then you can run it on any platform that supports the standard. ".NET Core 2.0" is a similar API, but is intended for end applications. That should be out of the discussion here. If you want to keep "legacy" code alive, you will also likely want to ship a NET45 or NET46 target. There are plenty of shops that are stuck on NET4x and won't be updating in the near future. Personally, I try to target all new .NET code to the standard, so you have the option of running portably (e.g. I'm trying to run on OSX and Win for this project). TL;DR - target I'd be happy to help out with this bit if you need some additional resources. |
|
Question,
1) can we build all of these with net core 2.1 SDK?
Hopefully yes,
2) How? All config files are in ortools/dotnet/
Thanks
Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53
00
Le lun. 30 juil. 2018 à 09:24, Jon Wagner <notifications@github.com> a
écrit :
… ".NET Standard 2.0" is basically a standard set of library APIs that you
code to. If or-tools targets .NET Standard, then you can run it on any
platform that supports the standard.
".NET Core 2.0" is a similar API, but is intended for end applications.
That should be out of the discussion here.
If you want to keep "legacy" code alive, you will also likely want to ship
a NET45 or NET46 target. There are plenty of shops that are stuck on NET4x
and won't be updating in the near future.
Personally, I try to target all new .NET code to the standard, so you have
the option of running portably (e.g. I'm trying to run on OSX and Win for
this project).
TL;DR - target netstandard20 and (net45 or net46)
I'd be happy to help out with this bit if you need some additional
resources.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#668 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKj17c7S5jIZ4WVskVOfGjJTVTEaaA8Fks5uLzMjgaJpZM4TjEOz>
.
|
|
You can use the same tools to build any of those targets, but if you want to compile a net45 target, I think you have to do the build on a windows machine. Since you're producing a nuget package already, your build system should support it. I'm new to your code. I'll take a deeper look at it tonight (TZ = America/New_York) |
|
@lperron @jonwagner I just want to be clear on the language here. Understandably, OR Tools does not exclusively serve the .NET community, nor even necessarily Windows only, nor should it. That's where folks like myself and @jonwagner enter in. Note, see also Target frameworks. Yes, netstandard is the "API surface area", akin to PCL, which is what you want, I should think. netcore is a run time, in theory extending across platforms. However, pretty sure both "targets" extend across platforms. Depending on the netstandard version, also supports net46 and net47 depending on whether you target netstandard1.x or netstandard2.x, but I could be wrong there, net45 may work here as well, I don't know. Similarly with @jonwagner, I've accepted that netstandard is the appropriate target for many of my sort of basic, building block assemblies. Core may be A runtime, does not need to be THE target that I adopt; I may want to target net47, depending on the requirement, for instance. The point is, when I consume a netstandard package, then I am assuming PCL-like flexibility until the very last moment when I need to target a run-time. Tracking this, or other issues, however, I've had the impression that the samples, etc, as been the bottle neck to packaging anything, never mind an RC. The sooner packaging can happen the sooner I can start updating my own wrappers when the dependencies are known. So anything we can do to clear the path for the "core" OR Tools assembly, if you will, I'm interested to see happen. This is my interest in it as you know. Others have been forging this path for now, so I am reporting as an interested bystander, but I can provide feedback, contribute further, etc, provided bandwidth is available. |
|
Thanks.
As seen in ortools/dotnet/OrTools/OrTools.csproj.in, we are currently
targeting netstandard 2.0.
So you think that on windows we should also target 4.x? Would 4.5 be the
right target?
Thanks
Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53
00
Le lun. 30 juil. 2018 à 09:44, Michael W Powell <notifications@github.com>
a écrit :
… @lperron <https://github.com/lperron> @jonwagner
<https://github.com/jonwagner> I just want to be clear on the language
here. Understandably, OR Tools does not exclusively serve the .NET
community, nor even necessarily Windows only, nor should it. That's where
folks like myself and @jonwagner <https://github.com/jonwagner> enter in.
Note, see also Target frameworks
<http://docs.microsoft.com/en-us/dotnet/standard/frameworks#supported-target-framework-versions>
.
Yes, netstandard is the "API surface area", akin to PCL, which is what you
want, I should think. netcore is a run time, in theory extending across
platforms. However, pretty sure both "targets" extend across platforms.
Depending on the netstandard version, also supports net46 and net47
depending on whether you target netstandard1.x or netstandard 2.x, but I
could be wrong there, net45 may work here as well, I don't know.
Similarly with @jonwagner <https://github.com/jonwagner>, I've accepted
that netstandard is the appropriate target for many of my sort of basic,
building block assemblies. Core may be *A* runtime, does not need to be
*THE* target that I adopt; I may want to target net47, depending on the
requirement, for instance. The point is, when I consume a netstandard
package, then I am assuming PCL-like flexibility until the very last moment
when I need to target a run-time.
Tracking this, or other issues, however, I've had the impression that the
samples, etc, as been the bottle neck to packaging anything, never mind an
RC. The sooner packaging can happen the sooner I can start updating my own
wrappers when the dependencies are known. So anything we can do to clear
the path for the "core" OR Tools assembly, if you will, I'm interested to
see happen. This is my interest in it as you know.
Others have been forging this path for now, so I am reporting as an
interested bystander, but I can provide feedback, contribute further, etc,
provided bandwidth is available.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#668 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKj17aF7LywpkxBksw3w0P5JVEJwTtNYks5uLzf1gaJpZM4TjEOz>
.
|
|
Or as seen here:
https://docs.microsoft.com/en-us/dotnet/standard/net-standard
netstandard2.0 and NET Framework 4.6.1 are the same, and both should work
OK.
I am just trying to do the minimum amount of relevant work. For instance,
for non windows, I have dropped mono in favor of .NET Core 2.1 as the build
tool.
Jon, I am open to all suggestions, pull requests to build the right nuget
package.
The immediate goal is a windows nuget.
Then we can look at building a cross platform nuget package. When this is
done, this will be the only binary channel for releasing OR-Tools on .NET.
Thanks for all your advices.
Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53
00
Le lun. 30 juil. 2018 à 09:48, Laurent Perron <lperron@google.com> a écrit :
… Thanks.
As seen in ortools/dotnet/OrTools/OrTools.csproj.in, we are currently
targeting netstandard 2.0.
So you think that on windows we should also target 4.x? Would 4.5 be the
right target?
Thanks
Laurent Perron | Operations Research | ***@***.*** | (33) 1 42 68
53 00
Le lun. 30 juil. 2018 à 09:44, Michael W Powell ***@***.***>
a écrit :
> @lperron <https://github.com/lperron> @jonwagner
> <https://github.com/jonwagner> I just want to be clear on the language
> here. Understandably, OR Tools does not exclusively serve the .NET
> community, nor even necessarily Windows only, nor should it. That's where
> folks like myself and @jonwagner <https://github.com/jonwagner> enter in.
>
> Note, see also Target frameworks
> <http://docs.microsoft.com/en-us/dotnet/standard/frameworks#supported-target-framework-versions>
> .
>
> Yes, netstandard is the "API surface area", akin to PCL, which is what
> you want, I should think. netcore is a run time, in theory extending across
> platforms. However, pretty sure both "targets" extend across platforms.
> Depending on the netstandard version, also supports net46 and net47
> depending on whether you target netstandard1.x or netstandard 2.x, but I
> could be wrong there, net45 may work here as well, I don't know.
>
> Similarly with @jonwagner <https://github.com/jonwagner>, I've accepted
> that netstandard is the appropriate target for many of my sort of basic,
> building block assemblies. Core may be *A* runtime, does not need to be
> *THE* target that I adopt; I may want to target net47, depending on the
> requirement, for instance. The point is, when I consume a netstandard
> package, then I am assuming PCL-like flexibility until the very last moment
> when I need to target a run-time.
>
> Tracking this, or other issues, however, I've had the impression that the
> samples, etc, as been the bottle neck to packaging anything, never mind an
> RC. The sooner packaging can happen the sooner I can start updating my own
> wrappers when the dependencies are known. So anything we can do to clear
> the path for the "core" OR Tools assembly, if you will, I'm interested to
> see happen. This is my interest in it as you know.
>
> Others have been forging this path for now, so I am reporting as an
> interested bystander, but I can provide feedback, contribute further, etc,
> provided bandwidth is available.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#668 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AKj17aF7LywpkxBksw3w0P5JVEJwTtNYks5uLzf1gaJpZM4TjEOz>
> .
>
|
|
@lperron Thanks for clarifying by the way; I was concerned we might be talking about targets themselves, but I probably read that incorrectly. We're on the same page; if you can target one, or a couple at most, instead of half a dozen, absolutely.
Assuming any sort of backwards compatibility is required, then it sounds like the right thing to do. I'd be content to leave it there as a dormant issue, and if anyone still needed it to up vote it, or give it a thumbs up, or something along these lines. For my concerns, I am more interested in tracking with the netstandard path these days, however. Maybe there is a corner case where I still need the |
|
I was only suggesting a .NET Framework target to not break existing users. The last version only targets If you build for netstandard20, it may work on 461, but may not (see dotnet/standard#64 for some notes) Definitely build for netstandard2.0. It will get you everything going forward. If your build process already runs on a Windows box, you might be able to target both for (almost) free just by specifying both targets in the .csproj file. (example: https://github.com/jonwagner/Insight.Database/blob/master/Insight.Database.Core/Insight.Database.Core.csproj) IMO: if you get it for free, keep net461 and netstandard20. If you have to choose, go netstandard20. I'll check out the code later... |
|
@lperron @jonwagner Good points. My understanding is that Personally, I'm less interested in anything but Anywho... Thanks, all! |
|
@paultrow @lperron @jonwagner One thing to also keep in mind also is whether you want to be on LTS. I'm not positive if that has to do with the SDK, per se; I'm a bit fuzzy on those details. As contrasted with a daily or nightly Core/SDK builds, let's say. |
|
We need .NET core 2.1.2 to build on linux.
We will switch to LTS when our 'monthly' release matches the next LTS
(before Q318).
Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53
00
Le lun. 30 juil. 2018 à 14:10, Michael W Powell <notifications@github.com>
a écrit :
… @paultrow <https://github.com/paultrow> @lperron
<https://github.com/lperron> @jonwagner <https://github.com/jonwagner>
One thing to also keep in mind also is whether you want to be on LTS. I'm
not positive if that has to do with the SDK, per se; I'm a bit fuzzy on
those details. As contrasted with a daily or nightly Core/SDK builds, let's
say.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#668 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKj17fISPw9lH0MPL7Tl--TkJvuf1REcks5uL3ZSgaJpZM4TjEOz>
.
|
|
@mwpowellhtx is right. If you can target netstandard1.6, you'll support net461 and everything after that for free. It looks like the build system is pretty clean and simple now, so it would be ideal if you can get the library to compile against netstandard1.6. You can test it by just switching the targetframework and doing a build. If 1.6 has all of the methods that you need, then you're done. If the build fails, then there's probably nothing you can do. I'll see if I can get it to build on my mac tomorrow. If you have any pointers/docs to how the dotnet build runs, please point me to them. |
|
normally, from sources,
install or-tools, install dependencies :
https://developers.google.com/optimization/install/dotnet/source_mac
Note: when we target 2.0, we do not need to install mono.
To target 1.6, I believe we need mono.
Then make dotnet
make test_dotnet
My idea was to target only netstandard 2.0 on unix, and maybe 1.6 and 2.0
on windows.
…--Laurent
Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53
00
Le lun. 30 juil. 2018 à 19:19, Jon Wagner <notifications@github.com> a
écrit :
@mwpowellhtx <https://github.com/mwpowellhtx> is right. If you can target
netstandard1.6, you'll support net461 and everything after that for free.
It looks like the build system is pretty clean and simple now, so it would
be ideal if you can get the library to compile against netstandard1.6. You
can test it by just switching the targetframework and doing a build. If 1.6
has all of the methods that you need, then you're done. If the build fails,
then there's probably nothing you can do.
I'll see if I can get it to build on my mac tomorrow. If you have any
pointers/docs to how the dotnet build runs, please point me to them.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#668 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKj17QTDvS5m5VE3IWrdoRIWUYboufc3ks5uL77LgaJpZM4TjEOz>
.
|
|
@lperron I couldn't advise you as to the Linux dependencies, but as far as the |
|
I spent some time trying to get or-tools to compile against I'll be building that and I can give you feedback on how the packaging looks. |
|
Yes, PInvoke stuff requires 2.0. I forgot.
2.0 it is then..
Thanks.
Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53
00
Le mer. 1 août 2018 à 10:10, Jon Wagner <notifications@github.com> a écrit :
… I spent some time trying to get or-tools to compile against netstandard1.6.
SWIG uses some classes that aren't available, and it would be non-trivial
to change it. So my recommendation is to target netstandard2.0 like you
currently are.
I'll be building that and I can give you feedback on how the packaging
looks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#668 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKj17bY-lyxwg7wfU8WHQniVd9nOh3j7ks5uMeEYgaJpZM4TjEOz>
.
|
|
To summary:
ps: in vacation last week sorry for the delay |
@Mizux @lperron
Able to build OrTools using .NET Standard 2.0. This makes it runnable in all frameworks (core 2.0, netfx 4.6.1) Includes C# & F# library. Still a work in progress but created PR to get some feedback.
make dotnetwill create the library andmake test_dotnetwill create and run the converted tests. Not all of them were converted.