ChakraCore NuGet package

[ormico]

I didn't see this already so I hope it isn't a duplicate.
I also didn't see it in the roadmap.

I read the quick-start guide on embedding ChakraCore, but following this guidance will make it hard to keep an embedded version up to date.
https://github.com/Microsoft/ChakraCore/wiki/Embedding-ChakraCore

A better solution would be if MS created a NuGet package for ChakraCore and auto-published it from its build server.

---

Maintainers' Update

@dilijev (added 2016-04-26 / last updated 2016-01-31):

Wiki: https://github.com/Microsoft/ChakraCore/wiki/NuGet-Packages
NuGet feed: https://www.nuget.org/packages/Microsoft.ChakraCore
MyGet feed: https://www.myget.org/feed/chakracore-preview/package/nuget/Microsoft.ChakraCore

Work Items

• Use build system to create and publish daily builds as NuGet packages to MyGet.org
• Add link to MyGet feed to README and/or Wiki (@liminzhu) (Add myget pre-built binaries info on README #1253)
• Create a NuGet.org feed to publish our official releases (once they are available)
• When available: Add NuGet.org feed link to README and/or Wiki (@liminzhu)
• When release 1.2 is finalized: Publish ChakraCore version 1.2 to NuGet.org
• Include build number in preview package special version strings
  • Format for preview packages: Microsoft.ChakraCore.<major>.<minor>.<patch>-preview-<build1>-<build2> (e.g. Microsoft.ChakraCore.1.3.0-preview-00008-12345). Commit hash is, as always, encoded in binary metadata.
• Preview builds of multiple branches: e.g. release/* and master (Infrastructure now exists but there's no compelling reason to publish preview builds of multiple release branches -- patch updates to already-released minor versions like 1.2 and 1.3 will be extremely minor so there's nothing meaningful to preview.)
• Reorganize package layout to enable Visual C++ projects to take a dependency on native NuGet packages and automatically integrate the ChakraCore binaries into a project. (see https://docs.nuget.org/consume/support-for-native-projects) (ChakraCore NuGet Package Implementation #2266 by @pre10der89)
• NuGet package spec (nuspec) consumable by .NET projects (ChakraCore NuGet Package Implementation #2266 by @pre10der89)
• Publish preview package for .NET for validation (ChakraCore NuGet package #85 (comment))
• Publish preview package for Native for validation (ChakraCore NuGet package #85 (comment))
• Publish an updated NuGet package for Native projects which supports NuGet automation (as above). (See Update version number to 1.4.1 and other changes in prep for release of new NuGet packages. #2435)
• Publish NuGet for .NET projects. (See Fix leak in deferred function dictionary.  #2345)

Follow-up Items

Moved follow-up work items to #2578

/cc @digitalinfinity @boingoing

[dilijev]

Thanks for the suggestion. We will look into the possibility of creating a ChakraCore Nuget package.

[resnyanskiy]

If there was a 'vote' button, I would pressed it for sure. Nuget package is a 'must have' for such project. Please, ensure that this package could be used in dnx project. Seems like https://github.com/robpaveza/jsrt-dotnet from @robpaveza could be a starting point.

[dilijev]

Thanks for reminding me @EdMaurer. I'll look into this asap.

[gulbanana]

this would be great for allowing asp.net core apps to use isomorphic javascript

[dilijev]

Just wanted to let everyone know that we're setting up our infrastructure to produce NuGet packages. Stay tuned.

[resnyanskiy]

@dilijev great news! Waiting ChakraCore package for dnx projects.

[dilijev]

Our infrastructure is set up to make NuGet packages and we are now hosting ChakraCore preview builds on MyGet.org:

https://www.myget.org/gallery/chakracore-preview
https://www.myget.org/feed/chakracore-preview/package/nuget/Microsoft.ChakraCore

These builds will be signed and can be used to trial development with ChakraCore and embedding ChakraCore into applications.

Some thoughts/questions:

• Including the PDB files in these packages makes them much larger than they otherwise would be. Most people would probably not need these symbols (unless they are developing and debugging ChakraCore itself). Is there another way to distribute these symbols?
• We should probably include the development headers in the NuGet package as well to tie the headers to the binary version. Otherwise, developers will need to get the headers from our repo as we've documented here. Should we include them in all packages or have a development package which includes all the extras (PDB files, header files, etc).

/cc @liminzhu @EdMaurer @digitalinfinity @curtisman

[ormico]

You could make a separate debug nuget package that included either the pdb and dll or just the pdb.

While it makes sense to me to include the headers, I haven't used c/c++ with nuget or needed header files for anything recently so I might be wrong. Someone with more recent c/c++ experience might have a different thought.

[dilijev]

It looks like there might be a supported pattern for native (C++) NuGet packages:
https://docs.nuget.org/consume/support-for-native-projects

That also suggests a pattern for making it easier to use NuGet to take a dependency on ChakraCore in a VS project.

Also I noticed that the MyGet website has integration with SymbolSource. This might be the best way to distribute debugging symbols, instead of in the binary distribution packages.
http://docs.myget.org/docs/reference/symbolsource

I'll add some tasks to the initial description that still need to be done to make consuming our NuGet packages a great experience.

It seems the thing to do is to create different packages that can be used in different scenarios (development, debugging, etc.) For example, TypeScript has two different packages that contain different tools depending on the development scenario.

[ormico]

are you planning to move to the main nuget index after you come out of preview? what it the reason for using myget.com for a public package?

[dilijev]

Yes, once we are out of preview we will move to the NuGet.org index (at least for the stable, official releases).

We were following the example of TypeScript using MyGet for preview builds, since we want to make sure nobody accidentally takes a dependency on the preview builds which will expire quickly and generally not be available for any significant length of time.

[dilijev]

Has anyone tried the packages? Any general asks?

[jimmcslim]

I have tried to build a simple HelloWorld console app, but adding the Nuget package fails:

Could not install package 'Microsoft.ChakraCore 1.2.4.53527-preview'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.5.2', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

Also tried for v4.5 and v4.6, no success.

[dilijev]

@jimmcslim Are you trying to build a .NET app? The contents of the NuGet package are intended for Native targets. It is also possible that in the current configuration, the NuGet package is simply a method for distributing the binaries and that NuGet will not automatically do the right thing. (You may have to manually add the references to the binaries.)

Contents of the package at the moment:

.
│   Microsoft.ChakraCore.nuspec
│   [Content_Types].xml
│
├───package
│   └───services
│       └───metadata
│           └───core-properties
│                   edd51c06e4ee4ea9958df28bd56b95d8.psmdcp
│
├───x64
│       ch.exe
│       ch.pdb
│       ChakraCore.dll
│       ChakraCore.pdb
│
├───x86
│       ch.exe
│       ch.pdb
│       ChakraCore.dll
│       ChakraCore.pdb
│
└───_rels
        .rels

[jimmcslim]

Yes was trying to build a .NET app. Is the intention for this Nuget package to ultimately work for .Net apps, e.g. also include the JSRT bindings for .Net and I'm off to the races adding JavaScript interop capabilities to my applications? Or should I be using packages like JavaScript Engine Switcher for .Net - Core and JavaScript Engine Switcher for .Net - Chakra?

[resnyanskiy]

@dilijev I thought NuGet package of ChakraCore will be for .net apps or even for .net core apps. Otherwise it looks a bit useless.

[dilijev]

@resnyanskiy Thanks for the feedback. We will have to look more deeply into supporting .NET targets in the NuGet package (/cc @liminzhu). Since we're a native project it's more straightforward to support a Native target for the moment. (NuGet has semantics for Native targets [reference linked above], but we are not yet implementing that semantic package layout.)

Since NuGet is still a good platform for distributing dependencies and we expect that native code projects will want to embed ChakraCore, we think that a NuGet package targeting native projects is a good idea. We acknowledge, however, that this is not the only (and not even necessarily the most-wanted) scenario we should plan to support. For now, Native is a stepping stone.

Side note: in it's current state, it's still not entirely useless, as we get to use the .nupkg (which is a .zip) as a way to distribute our official preview binaries. :P

[dilijev]

@digitalinfinity - @liminzhu mentioned this to me and I wanted to get your thoughts on it / get it on your radar:

• MyGet feed for preview builds of Linux targeted binaries (either for devs extracting binaries from the packages or for use in Linux version of NuGet). /cc @digitalinfinity

Also (very much future work): after we have something release-ready, getting the package added to Canonical's package database a .deb package feed so that one could do something like sudo apt-get install libchakracore and build against it.

Edit 2016-07-15: I forgot that we can create our own apt-get package feed and host our binaries there. That's probably the approach we want to take.

[Oceanswave]

+1

This is already mentioned in the roadmap, but would be great if xplat builds were also included with the nuspec -- similar to how netcore distributes libuv, having the package be the combination of platform specific builds, which can be taken independently if desired.

https://github.com/aspnet/libuv-package
https://github.com/aspnet/libuv-build/tree/dev/build

(Note that this doesn't reference distributing xplat libs on other package managers e.g. apt-get or brew for instance, only allowing xplat libs to be distributed on nuget to be consumed from things like netcore)

[dilijev]

Thanks for the reference to libuv, @Oceanswave -- it's good to know which layouts by other packages are preferred by our users. We'll look into this!

[dilijev]

We've created preview packages using the new dfefinitions from #2266 and published them to the MyGet feed:

.NET: https://www.myget.org/feed/chakracore-preview/package/nuget/Microsoft.ChakraCore
Native: https://www.myget.org/feed/chakracore-preview/package/nuget/Microsoft.ChakraCore.vc140

We welcome your feedback!

Thanks @matthargett and @pre10der89 for all your help in making this a reality!

[matthargett]

Our pleasure! Thanks to @bluejeans for encouraging us to collaborate on upstream projects in the process of making an awesome next-generation experience for our customers 😃

[dilijev]

Closing this issue as all of the main functionality work items have been completed. I created a an issue for any follow-up items: #2578