Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    ArsenShnurkov
    @ArsenShnurkov
    @ostroffjh ^^
    That's will exclude the possibility that I forgot to add something to github (or that I added it to different branch)
    especially important the content of ./files/15.9/xbuild-Microsoft.Build.Tasks.csproj
    because it contain defines for compiler
    Jack Ostroff
    @ostroffjh
    @ArsenShnurkov the sums all match. However, I'm having enough other problems that I think it may be best for me to remove all msbuild related packages and install them all from scratch.
    Jack Ostroff
    @ostroffjh
    I seem to have a mix of packages with net45 and net46. Does it matter, or should I change all to one or the other?
    ArsenShnurkov
    @ArsenShnurkov
    You have an compilation error. The proper way to solve it is to undesrtand where that code is located and how it's dependencies are installed. Plain reinstallation is just a waste of time. Right now I don't have the understanding of that source code piece. I think (guess) that problem of 4.5/4.6 mixing is irrelevant.
    Jack Ostroff
    @ostroffjh
    Well, I already uninstalled, and added the shnurise overlay to eliminate any changes I made in ebuilds. I'm getting a circular dependency of msbuildtasks -> msbuild -> msbuildtasks. (15.9) I don't see any USE flags causing optional dependencies, and I don't see a path to starting with any earlier versions. While I agree with your thought on the compilation error, it seems to me like a problem with versions (which I suppose does mean how the code's dependencies are installed) but I'm also stuck on how to track down the problem.
    ArsenShnurkov
    @ArsenShnurkov
    Yes, that circular dependency really exists, and this is the bug (i.e. that dependency shuld be removed before continuing).

    https://github.com/ArsenShnurkov/shnurise/blob/master/dev-util/msbuild/msbuild-15.9.20.62856-r3.ebuild#L48

    =dev-dotnet/msbuildtasks-1.5.0.240-r1

    https://github.com/ArsenShnurkov/shnurise/blob/master/dev-dotnet/msbuildtasks/msbuildtasks-1.5.0.260_pre-r1.ebuild#L75
    emsbuild "/p:SignAssembly=true" "/p:PublicSign=true" "/p:AssemblyOriginatorKeyFile=${KEY2}" "$(metafile_to_build)"

    I don't remember why msbuild depend on msbuildtasks
    ArsenShnurkov
    @ArsenShnurkov
    may be I will move that dependency to msbuild-meta ebuild
    which is not created yet
    Jack Ostroff
    @ostroffjh
    You do have an msbuild-meta.
    Jack Ostroff
    @ostroffjh
    I did find a solution to installing without any 15.9, but even that failed for msbuildtasks:0::dotnet due to not finding xbuild_strong. Making a local copy, adding xbuild to inherit, and copying xbuild.eclass to my local overlay didn't help (unless I got something wrong) but msbuildtasks:1::dotnet did emerge, so I think I can now try to emerge the 15.9 versions.
    ArsenShnurkov
    @ArsenShnurkov
    Now I see msbuild-meta too. xbuild_strong is missing "e" letter in they name.
    ArsenShnurkov
    @ArsenShnurkov
    moved dependency - ArsenShnurkov/shnurise@91b9bf2
    Jack Ostroff
    @ostroffjh
    I got msbuild-tasks-api, msbuild-defaulttasks, and msbuild all 15.9 installed. I'll resync everything and see what else (if anything) I need to upgrade to 15.9, and what else upgrades from the new sync. (That xbuild_strong missing is in msbuildtasks::dotnet. Can you fix that, or should I file a bug?)
    ArsenShnurkov
    @ArsenShnurkov
    I can create PR to dotnet overlay, but I don't see the line
    Jack Ostroff
    @ostroffjh
    Actually not quite the same issue - dotnet overlay msbuildtasks 240-r3 and 240-r2 call exbuild_strong but do not inherit xbuild.
    ArsenShnurkov
    @ArsenShnurkov
    i don't want to fix that right now. My plan is following: 1) package asmspy project (requires 1 additional lib), 2) make the new (15.9) msbuild working, 3) create PR to dotnet overlay adding 15.9 and removing everything else
    if you wish, you can create PR to dotnet overlay yourself
    Jack Ostroff
    @ostroffjh
    Reasonble. I agree no point in fixing something soon to be removed. Interesnting - I see that msbuild 16.0 has been released
    ArsenShnurkov
    @ArsenShnurkov
    thanks. I will try to finish 15.9 first anyway, because 16.0 probably will bring new problems
    Jack Ostroff
    @ostroffjh
    Good news - right now I have no errors within any dotnet related build. However, the project I use dotnet for is giving me error MSB4132: The tools version "15.0" is unrecognized. Available tools versions are "2.0". Is that something that needs to be addressed in that other project, or do I just have some new config problem?
    ArsenShnurkov
    @ArsenShnurkov
    you need a config file for msbuild
    Jack Ostroff
    @ostroffjh
    In general, or as part of that project?
    ArsenShnurkov
    @ArsenShnurkov
    Jack Ostroff
    @ostroffjh
    Thanks.
    ArsenShnurkov
    @ArsenShnurkov
    *experementing
    Jack Ostroff
    @ostroffjh
    That needs to be MSBuild.exe.config in the same dir as MSBuild.exe? It looks like it needs more stuff in it, as I'm getting a bunch of couldn't load Microsoft.Build.Utilities.
    ArsenShnurkov
    @ArsenShnurkov
    that's why I want to package asmspy ( https://github.com/mikehadlow/AsmSpy )
    I have the same problem with Utilities, and didn't solved it yet
    Jack Ostroff
    @ostroffjh
    Makes sense. As I've said, my problem here is that I'm just barely able to follow how all this dotnet stuff works. I can modify things if I have a pattern or template, and if I have some sense of where it's actually failing. I'm actually trying to compile that other project both on my Gentoo box and on an Artix Linux box, and sometimes the errors on one help me solve different errors on the other.
    ArsenShnurkov
    @ArsenShnurkov
    I am in the same situation. Here is my bug from 2011 - https://bugs.gentoo.org/354543 which I am trying to complete
    Jack Ostroff
    @ostroffjh
    Mine is F-Spot which is a photo manager, and was dropped from portage a few years ago because it was so out of date. It's not totally unsupported, but activity is very slow. I'm getting a bit more desperate about it now because my installed version finally stopped working a few weeks ago.
    Jack Ostroff
    @ostroffjh
    Another generic question (not Gentoo related) in my gac, 0738eb9f132ed756 is the public key for most newer assemblies including all 15.9 stuff, but b03f5f7f11d50a3a is on many older ones. If I have an application calling for 0738eb9f132ed756, is there any reasonable way to let it use a newer version with the newer key? (I'm assuming the API for that assembly has not changed too much.)
    ArsenShnurkov
    @ArsenShnurkov
    There are 2 files - MSFT.keq and mono.snk. And there are some topic - https://www.mono-project.com/docs/advanced/assemblies-and-the-gac/#public-key-token-remapping
    .csproj file contain Reference lines for dependencies, and these lines specify which token to use
    Jack Ostroff
    @ostroffjh
    @ArsenShnurkov If I emerge msbuild-15.9.20.62856-r3 from your overlay, it says "Ebuild doesn't contain USE_DOTNET=' and "-- USING .NET 4.0 FRAMEWORK --". If I add lines for net46 (which is what you set in the ebuild) to the dotnet.eclass (4.5 was the highest) emerge gives the same output but ebuild prepare says USING .NET 4.6. I don't know if I missed some step, or have a different problem. Doesn't an emerge use the eclass files from the same repository as the ebuild file?
    ArsenShnurkov
    @ArsenShnurkov
    I think that you have no problems. Nobody installs several mono engines into slots, and we use latest vesion. So there is only one mono in you system. These settings have no effect I think.
    ArsenShnurkov
    @ArsenShnurkov
    Current status: msbuild 15.9 works by itself, but to compile .net projects it requires at least 2 more SDKs (which are not packaged) - gentoo/dotnet#335 and gentoo/dotnet#422
    ArsenShnurkov
    @ArsenShnurkov

    "this NOTABUG WONTFIX response is pretty damned disgusting. Monodevelop refuses to build because nuget doesn't work, and the maintainer says the solution is to use an older ebuild that no longer compiles.

    Meanwhile, game developers using C# have to go elsewhere (as if sabayon or calculate didn't use this overlay as a base) because you think this required package that prevents monodevelop to even build in gentoo is hunky-dory because WORKSFORME.

    Your obstructive response to this very real issue makes you officially the Ullrich Drepper of Gentoo. That's not a compliment. What he did to keep GCC down is what you're doing to C#/Mono on Gentoo." - https://github.com/gentoo/dotnet/issues/244#issuecomment-497457457

    ArsenShnurkov
    @ArsenShnurkov
    @ostroffjh: gentoo/dotnet#428
    Denis Lisov
    @tanriol
    Is there some specific reason that dotnetcore-sdk has only 1.0/1.1 series while 2.1/2.2 are binary only?
    ArsenShnurkov
    @ArsenShnurkov
    nope, go ahead and implement anything you want