[CSharp] #2021 fixes nuget packaging options to avoid missing dll exceptions #2024

listerenko · 2017-09-25T06:32:59Z

@ericvergnaud Hi,
I modified csproj options a bit, now I can get a working nuget package locally without the issue we described in #2021.
I added .net 3.5 as a target to "main" csproj along with netstandard, since it's easier to keep track of requirements for both sets of api's when editing code and, ideally, both targets can be packed into a nuget package with a single command. Right now it's possible only on Windows via msbuild /t:pack or Visual Studio; unfortunately, due to dotnet/msbuild#1333, right now dotnet build pack does not work for .net 3.5 target the way it should, so I adjusted the existing script to create packages from .nuspec and different solutions for different targets.

ericvergnaud · 2017-09-25T14:32:29Z

Hey!
thanks for the help, much appreciated.
Up to now I've always released from my mac using Mono.
Not sure if build-nuget-package.sh is of much use on a wintel box..
Would it be too much to ask if you can provide a powershell script for releasing from Windows?

listerenko · 2017-09-26T06:15:14Z

Nah, it's a single msbuild call, so that's ok, I added the script, although the old one should continue to work with mono, it's just less convenient. It's cumbersome to have two ways to make a package, however.

ericvergnaud · 2017-09-26T13:45:04Z

Thanks
From your previous comment; I thought that due to dotnet/msbuild#1333 packaging was only possible on windows. Hence my ask for the script.
What am I missing?

listerenko · 2017-09-27T03:53:59Z

Sorry, didn't make myself clear enough. It's not about windows, it's an issue with dotnet cli . You can't use it both on windows and Linux to build projects targeting .net 3.5, you need full msbuild for it, or, in your case, xbuild from mono. So I edited your existing script to make dotnet build only standard target (explicitly setting it in build command parameters), the rest is still done by xbuild and nuget. The downside is that you have two ways to make a package and three sln/csproj files, so it gets a bit confusing, but the only way to get rid of them are either dropping .net 3.5 support (in that case you just use single csproj and dotnet build pack on all platforms), or dropping requirement to be able to build package with both targets on non-windows machine. Anyone will still be able to compile netstandard target on any platform, but windows will be required to make nuget package with both standard and net3.5 dll's.

listerenko · 2017-09-27T03:56:06Z

Or you leave everything as is, this way you can build everything everywhere, but have to cope with multiple csproj's and duplicating package metadata in nuspec and csproj.

ericvergnaud · 2017-09-27T15:01:17Z

Ok I guess we will publish from windows until MS fixes #1333 .
Then we'll get back to a single unified way that works on all platforms.
Again, many thanks for your help with this.
@parrt are you comfortable with this?

parrt · 2017-09-27T15:16:01Z

@ericvergnaud can you explain the changes for me? Is it just packaging? new name?

listerenko · 2017-09-28T05:39:50Z

if you are comfortable with publishing from windows, excess csproj/sln should probably be removed to reduce clutter. It will still be possible to compile .net standard version on any os supported by .net core.

@parrt hi. It's about more simple packaging process (all metadata in single file, both target frameworks are defined in single csproj file, single msbuild call for all restore/build/pack operation); defining both target frameworks (.net 3.5 and .net standard) in single csproj allows IntelliSense to perform analysis against both targets, thus preventing you from introducing changes incompatible with any of the platforms.
During build both targets will produce dll with the same name, yes, since it's more correct behaviour when targeting multiple runtimes and working with .net standard api's (or you'll get weird dll not found errors depending on runtime you use to build an app transitively dependent on this library, that's what #2021 was initially about).

parrt · 2017-09-28T18:14:04Z

Hmm...well,I really need to rely on you guys for correct C# behavior and packaging. Am I still able to build from Mac? How does this affect the nuget packages we have now?

listerenko · 2017-09-29T05:41:42Z

You can build from any platform supported by .net core tools (including Mac) using command dotnet build -c Release -f netstandard1.3 Antlr4.dotnet.sln. You'll get working dll targeting .net standard, which you can consume from both mono and .net core projects. I'm not sure about building for .net 3.5 using mono, I don't know if xbuild supports new csproj format, but this should not be an issue anyway since libraries built for .net standard are supported by current mono version.
As for nuget package, supported platforms will remain the same (basically everything .net related after 3.5), but the issue my co-worker described in #2021 will be fixed.

parrt · 2017-09-29T17:53:26Z

Ok, i'm not sure exactly what @ericvergnaud wants me to make a decision on. I don't know much about the C# ecosystem.

ericvergnaud · 2017-09-30T05:26:08Z

@parrt our current CI is not affected, but our release process to Nuget is.
Due to bugs/limitations, we need to publish from Windows, and I want to make sure you are comfortable with this.

parrt · 2017-09-30T19:50:47Z

Ah! Hmm...I think I can get a Windows VM running on my mac. would it require installation of all M$ dev tools and such or just nuget stuff?

ericvergnaud · 2017-10-01T04:04:42Z

I believe the community edition suffices:
https://www.visualstudio.com/fr/thank-you-downloading-visual-studio/?sku=Community&rel=15
@kaedvann can you confirm?

listerenko · 2017-10-02T05:15:46Z

Yes, community edition will work, you really require only msbuild anyway. Oh, and to enable building for .net 3.5 on modern windows you will need to explicitly enable it in "Windows Features", like described here, and add .net 3.5 sdk during visual studio install (they improved installer in 2017, so you'll only need to check relevant sdk's in 'individual components' tab)

parrt · 2017-10-02T19:27:00Z

Ok, So there is no name change or anything like that on the visible nuget product?

parrt · 2017-10-02T19:42:21Z

Ok, i have windows 10 x64 in vmware with Visual Studio Comm 2015. Is that sufficient?

ericvergnaud · 2017-10-02T22:57:31Z

Can you try from cmd line in c# folder: Powershell ./build-nuget.ps1 (Not sure about the exact script name) Envoyé de mon iPhone

…

Le 3 oct. 2017 à 03:42, Terence Parr ***@***.***> a écrit : Ok, i have windows 10 x64 in vmware with Visual Studio Comm 2015. Is that sufficient? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

listerenko · 2017-10-03T05:50:25Z

@parrt just to make sure, is it visual studio 2015 or visual studio 15 (which is in fact visual studio 2017, they need some consistency on naming)? If really is vs 2015 (it will have version id like 14.0.25420.10 in "about" window), it will not work. If the version shown is something like 15.3.3 or 15.3.4, than it's fine. You'll need to add msbuild to PATH (it'll be something like C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin) and then execute the script I added (runtime/CSharp/runtime/CSharp/Build-NugetPackage.ps1) from Powershell.

parrt · 2017-10-03T15:51:47Z

Pretty sure it's 2015 not 15. Heh, will the mac version of VS work?

ericvergnaud · 2017-10-03T15:57:23Z

Not sure about the mac I installed https://www.visualstudio.com/thank-you-downloading-visual-studio/?sku=Community&rel=15 <https://www.visualstudio.com/thank-you-downloading-visual-studio/?sku=Community&rel=15> That’s VS2017 community, so should work

…

Le 3 oct. 2017 à 23:51, Terence Parr ***@***.***> a écrit : Pretty sure it's 2015 not 15. Heh, will the mac version of VS work? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2024 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLYJGaMH83BJX2XjgvV01RZRkTb7zToks5solgYgaJpZM4PiQjB>.

parrt · 2017-10-03T16:10:28Z

ok, i'm away from work machine today so will try later.

listerenko · 2017-10-09T05:32:36Z

@parrt hi, any luck with setting up renewed build?

parrt · 2017-10-09T23:44:13Z

Okay it looks like I have Visual Studio Community 2015

I am downloading 2017 now.

parrt · 2017-10-09T23:49:27Z

Ok, now says:

Do I need any other installed products?

listerenko · 2017-10-10T12:41:26Z

VS is fine, we just need to ensure you have necessary sdk's and stuff

ensure msbuild is added to PATH, is should be accessible from command line (it is installed with visual studio, just not added to PATH automatically)
ensure .net 3.5 is enabled in Programs & Features (I described it a bit earlier)
.net core sdk should be installed (dotnet --version works in command line and shows something meaningful)

Hm, that should be it.

parrt · 2017-10-10T19:28:20Z

Ok, enabled .net 3.5. and msbuild appears to work. I had to reboot after setting the path. hahaha. just like old times.

.net core sdk shows 2.0.0 from prompt. Sound good?

listerenko · 2017-10-11T06:55:32Z

Yup, now the script runtime/CSharp/runtime/CSharp/Build-NugetPackage.ps1 should create you a nuget package with both targets and all relevant metadata filled.

listerenko · 2017-10-18T05:05:45Z

@parrt Hi, sorry to bother you, but have you had any lack with packaging?

parrt · 2017-10-18T15:10:24Z

hiya. just finished school semester and today off to 3 or 4 day vacation. i hope to start antlr stuff again on Monday

…n transitive dependencies

listerenko · 2017-11-13T06:32:42Z

@xied75 that was helpful, thank you.
@parrt Hi, I got appveyor to produce nuget packages(https://ci.appveyor.com/project/parrt/antlr4/build/4.7.1-SNAPSHOT+AppVeyor.1350/artifacts)
I also updated the doc about releasing and removed unnecessary package.nuspec to avoid confusion. So it looks like you can publish the package from any platform as long as appveyor works and you have nuget.exe.
I tried to remove other excess .csproj files, but they are somehow used in testing, which I couldn't completely figure out and rewrite to new csproj, so I'll guess they'll live till next improvement attempt.

parrt · 2017-11-13T22:31:55Z

great! so if @ericvergnaud signs off on this I'll merge. I can see the artifact :)

listerenko · 2017-11-23T05:51:23Z

Has been a while. @ericvergnaud ?

ericvergnaud · 2017-11-23T13:13:09Z

Sorry missed this I’ll look into it this weekend Envoyé de mon iPhone

…

Le 23 nov. 2017 à 13:51, Rostislav Listerenko ***@***.***> a écrit : Has been a while. @ericvergnaud ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

ericvergnaud · 2017-11-25T07:54:48Z

@parrt if it works for you, it works. blessed

parrt · 2017-11-25T16:43:14Z

Seems to work and I downloaded an artifact, though I didn't test the artifact as I didn't know immediately how to test it. @kaedvann can you verify that the artifact at appveyor is correct?

parrt · 2017-11-25T18:28:04Z

@kaedvann Hmm...something is wrong with the C# build on travis: https://travis-ci.org/antlr/antlr4/jobs/307183842 can you take a look?

ewanmellor · 2017-11-25T20:10:13Z

@parrt That failure is #2078 and there is already a PR to retry around it: #2124 .

parrt · 2017-11-25T20:17:30Z

Cool. i just merged that one and this one. thanks VERY much for pushing this through!

listerenko · 2017-11-26T07:13:27Z

Great! But I still would like to answer @parrt . Yes, I checked the produced artifact, it seemed to resolve the initial issue this PR was about. About testing - NuGet has a command to install package from local file, something like Install-Package SomePackage -Source C:\PathToThePackageDir\. If you have a test project or something, you could add this nuget to the project and run some checks. Since the packages contains two dll's, you'll need to run the tests both on full framework (Mono or Windows, shouldn't matter) or .NET Core runtime. Oh, and as the package is in fact a zip-archive, you could unpack it and check .nuspec inside to ensure all the metadata about the package is correctly filled (I checked that too, but still, anything can happen).
Look forward to seeing this updated package on nuget. :)

xied75 · 2017-11-27T13:20:35Z

@parrt @ericvergnaud I wonder should we version the new nuget package to e.g. 4.7.2? So that it won't replace the current 4.7.1 to avoid breaking already running builds.

ericvergnaud · 2017-11-27T15:20:17Z

Hi There is no plan to replace the current package (if that’s even possible which would be frightening) Envoyé de mon iPhone

…

Le 27 nov. 2017 à 21:20, Dong Xie ***@***.***> a écrit : @parrt @ericvergnaud I wonder should we version the new nuget package to e.g. 4.7.2? So that it won't replace the current 4.7.1 to avoid breaking already running builds. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

parrt · 2017-11-27T16:38:04Z

Oh right we did some weird thing with numbering to get out a release. can we do 4.7.1.1?

ericvergnaud · 2017-11-27T17:00:23Z

Definitely Envoyé de mon iPhone

…

Le 28 nov. 2017 à 00:38, Terence Parr ***@***.***> a écrit : Oh right we did some weird thing with numbering to get out a release. can we do 4.7.1.1? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

xied75 · 2017-11-27T17:03:01Z

Not that good if considering SemVer is not using the 4th number.

parrt · 2017-11-27T18:28:49Z

Yeah but better than 4.7.2 which would mean 4.7.1 ;)

parrt · 2017-11-29T17:39:51Z

@ericvergnaud @kaedvann can you alter the build config for 4.7.1.1? I'd like to push out 4.7.1 soon. thanks!

listerenko · 2017-11-30T07:44:22Z

@parrt it is only the <Version> node in the Antlr4.Runtime.dotnet.csproj file. No other adjustments required

parrt · 2017-12-04T22:12:59Z

Ok, done: b9adef5

Add -f netstandard1.3 to the dotnet build command used on Travis. This has been necessary since PR antlr#2024, and the build has been silently failing all this time.

listerenko added 2 commits November 12, 2017 16:11

#2021 fixes nuget packaging options to avoid missing dll exceptions i…

5b5f195

…n transitive dependencies

#2021 nuget artifact in appveyor

9ec6c66

listerenko changed the title ~~#2021 fixes nuget packaging options to avoid missing dll exceptions~~ [CSharp] #2021 fixes nuget packaging options to avoid missing dll exceptions Nov 16, 2017

parrt added this to the 4.7.1 milestone Nov 25, 2017

parrt added comp:build target:csharp labels Nov 25, 2017

parrt merged commit 963d44f into antlr:master Nov 25, 2017

[CSharp] #2021 fixes nuget packaging options to avoid missing dll exceptions #2024

[CSharp] #2021 fixes nuget packaging options to avoid missing dll exceptions #2024

Conversation

listerenko commented Sep 25, 2017 • edited

ericvergnaud commented Sep 25, 2017 • edited

listerenko commented Sep 26, 2017

ericvergnaud commented Sep 26, 2017

listerenko commented Sep 27, 2017 • edited

listerenko commented Sep 27, 2017

ericvergnaud commented Sep 27, 2017

parrt commented Sep 27, 2017

listerenko commented Sep 28, 2017

parrt commented Sep 28, 2017

listerenko commented Sep 29, 2017

parrt commented Sep 29, 2017

ericvergnaud commented Sep 30, 2017

parrt commented Sep 30, 2017

ericvergnaud commented Oct 1, 2017

listerenko commented Oct 2, 2017

parrt commented Oct 2, 2017

parrt commented Oct 2, 2017

ericvergnaud commented Oct 2, 2017 via email

listerenko commented Oct 3, 2017

parrt commented Oct 3, 2017

ericvergnaud commented Oct 3, 2017 via email

parrt commented Oct 3, 2017

listerenko commented Oct 9, 2017

parrt commented Oct 9, 2017

parrt commented Oct 9, 2017

listerenko commented Oct 10, 2017

parrt commented Oct 10, 2017

listerenko commented Oct 11, 2017

listerenko commented Oct 18, 2017

parrt commented Oct 18, 2017

listerenko commented Nov 13, 2017 • edited

parrt commented Nov 13, 2017

listerenko commented Nov 23, 2017

ericvergnaud commented Nov 23, 2017 via email

ericvergnaud commented Nov 25, 2017

parrt commented Nov 25, 2017

parrt commented Nov 25, 2017

ewanmellor commented Nov 25, 2017

parrt commented Nov 25, 2017

listerenko commented Nov 26, 2017

xied75 commented Nov 27, 2017

ericvergnaud commented Nov 27, 2017 via email

parrt commented Nov 27, 2017

ericvergnaud commented Nov 27, 2017 via email

xied75 commented Nov 27, 2017

parrt commented Nov 27, 2017

parrt commented Nov 29, 2017

listerenko commented Nov 30, 2017 • edited

parrt commented Dec 4, 2017

listerenko commented Sep 25, 2017 •

edited

ericvergnaud commented Sep 25, 2017 •

edited

listerenko commented Sep 27, 2017 •

edited

listerenko commented Nov 13, 2017 •

edited

listerenko commented Nov 30, 2017 •

edited