I'm trying to create a NuGet package that targets both Windows Store XAML/C# and Windows Store HTML/JS. The Windows Store XAML/C# DLLs can be placed inside of lib/NETCore45 (or now lib/Windows8) and they will install fine on to Windows Store XAML/C# projects. However, when trying to install on a Windows Store HTML/JS project it says that the NuGet package does not support the project type.

My current work around is to place the Windows Store XAML/C# .DLLs and the Windows Store HTML/JS .js files in their own separate folders and then use tools\NETCore45\install.ps1 (or now tools\Windows8\install.ps1) to detect if the $project.Type is C# or JavaScript and install the proper files to the project.

Is this the recommended approach? Is there already support for this scenario? Will this scenario be supported in the future?

Thanks

Simon

Can you paste the exact error message? Are you installing via the dialog or the Package Manager console?

Currently, NuGet doesn't distinguish a XAML/C# project versus a HTML/JS one. Maybe we should support it.

To make sure I understand correctly, you want the .DLL to be added only for the C# project, but not HTML/JS one, and you want the .js file to be installed only for the HTML/JS project, right?

Sure. Below is the output form the Package Manager Console and from the Manage NuGet Packages Window in Visual Studio.

From Package Manager Console:

PM> Install-Package PackageNameHere -verbose
...
Added file OUTPUT HERE
...
Successfully installed 'PackageNameHere'
...
Added file OUTPUT HERE
...
Removed file OUTPUT HERE
...
Successfully uninstalled 'PackageNameHere'.
Install failed. Rolling back...
Install-Package : Failed to add reference to 'Assembly.Name.Here'.
At line:1 char:1
+ Install-Package PackageNameHere -verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Install-Package], InvalidOperationException
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.InstallPackageCommand
 
PM> 

From Manage NuGet Package Window:

Successfully installed 'PackageNameHere'.
Successfully uninstalled 'PackageNameHere'.
Install failed. Rolling back...
Failed to add reference to 'Assembly.Name.Here'.

Yes, that is correct. I want to add .DLL files to a C# project and not an HTML/JS project (Visual Studio's Add Reference will only allow you to reference *.winmd files for a HTML/JS project). And then I want to install .js files to an HTML/JS project. I would think at the very least the C# .DLLs should NOT cause the install to fail on a HTML/JS project.

Also, here is my Windows8\install.ps1 work around:

param($installPath, $toolsPath, $package, $project)

switch ($project.Type) {
    "C#" {
        $project.Object.References.Add("path to DLL")
    }
    "JavaScript" {
        $jsFolderProjectItem = $project.ProjectItems.Item("js")
        $jsFolderProjectItem.ProjectItems.AddFromFileCopy("path to js file")
    }
}

Simon

Yup, this is what I expected. NuGet doesn't distinguish between C# project and HTML/JS one, so it tries to install the .dll into the HTML/JS too, which fails because HTML/JS can't have reference to .NET project.

What you are doing is the best solution in the current situation. Another alternative is to split it into two different packages.

I'll make sure we address this for the upcoming release.

In 2.2, we will add support for these 3 profiles to allow you to distinguish the three different flavors of Windows Store apps. These are:

• windows8-javascript (or win8-javascript or netcore45-javascript): apply to Windows Store JavaScript projects.
• windows8-managed (or win8-managed or netcore45-managed): apply to Windows Store C# or VB projects.
• windows8-native (or win8-native or netcore45-native): apply to Windows Store C++ projects. (However, since we’re not supporting C++ projects yet, this moniker is not applicable.)

To maintain backward compatibility, the current windows8 (and netcore45) moniker will continue to be compatible with all three project flavors.

If a package contains both windows8 and one of the above specific profiles, NuGet will pick the specific profile. For example, if a package contains both windows8 and windows8-managed, then when NuGet installs it into a C# Windows Store project, it will pick windows8-managed.

Any thought or feedback?

That sounds goods :). The only thing I might be concerned about is the windows8-javascript folder and the types of files that would good into there. I would think that it would take JavaScript files and not DLLs, correct?

Simon

You can install .winmd components into JS projects too. So, you can put JavaScripts file in the contents folder, and .winmd files in the lib folder.

Ok. So if I have .js files for Win8, they would be placed in contents\windows8-javascript?

Yes. And .winmd files will go into lib\windows8 or lib\windows8-javascript. Both will work.

In my nuget 2.2 package if I create the following files

Contents\windows8-javascript\default.html.pp
Contents\windows8-javascript\js\default.js.pp
Contents\windows8-managed\MainPage.xaml.pp
Contents\windows8-managed\MainPage.xaml.cs.pp

Will it have the effect of adding content from those nuget package files to the to the default html/js and xaml/c# project template pages with the same name and if not is there a file naming convention I will be able to use to achieve that?

No, the .pp files can only be used to add new files to the project. If there are already existings files with the same names, the .pp files will be ignored. There is no way to work around that.

thanks for details.  would authoring a Tools\install.ps1 routine that looked for and modified contents of these existing project template files be an acceptable nuget package behavior or against policies?

We don't have strict "policies" per se, but I'm skeptical about such approach.

First of all, it would be difficult to get the behavior right. Merging XML content may be possible, but .js and .cs code would be much more difficult.

Second, you need to also be able to undo the merge when users uninstall your package.

Perhaps, you can explain what you are trying to do and we can find a work around?

I want to be able to insert custom message dialog [ using from scratch sources in case of html/js and using callisto nuget package control in case of xaml/c# ] into default start page of standard issue project template setups.  I'm thinking that I should instead be looking at settings flyout approach instead wihch allows me to surface UX to do user input data collection irrespective of what view page is currently running.

A common approach that I see people do is to add a readme.txt file which tells user what to do after installation succeeds. NuGet automatically opens this file after installation. In that file, you can include your code snippet and instructs user where to insert it.

I admit it's not ideal, but it's the best compromise.

that'll work.  ultimately I think the by design story for not allowing one to easily modify existing view/code behind/style page content makes sense in the context of the overall nuget package install, update, uninstall experience.