Closed johnataylor closed 5 years ago
@josesimoes we have started working on this. I don't have a hard ETA on this yet.
Still no progress?... :(
@controlflow Happy new year! Several members of the team returned from holidays last week (I just returned from my honeymoon on the 8th). We are focusing on finishing the last bit of self-contained license related work which should be done this month. Right after, we'll pick up self-contained icon work in Feb. You'll see new tasks being created under this issue as we make progress.
@karann-msft Fantastic to hear. Thank you so much!
Any status on this issue?
@elmojo - we just finished the self-contained license story (which also included a lot of work around licenses.nuget.org as well as the client side experience). We have started working on self-contained icons. and it is currently in the technical design phase.
On a side note - I will be prsenting at the MVP summit on the 20th. If anybody here is attending, do come by and say hi!
What does the 'Epic' label signify?
Hi @adamralph This is probably related to types of dev work. At least in terms of JIRA that I use daily:
Epics are usually collections of the above types of issue that are too big to be done in one piece of work, that all follow a theme.
A starter for 10: https://github.community/t5/How-to-use-Git-and-GitHub/Epics-amp-GitHub-issues/td-p/13493
@ncook-vero thanks for the info.
Can you offer any explanation of why this is an epic? I'm having a hard time believing "Package Icon should be able to come from inside the package" is a collection of issues that "are too big to be done in one piece of work, that all follow a theme".
Hi @adamralph
I can't give you much insight I'm afraid, as I'm a consumer of NuGet and not a producer :)
I'd rather see something broken down into tiny milestones than risk a regression by doing too much at once, though. They're probably trying to make sure they build this feature out of common code and adhere to some internal common practice, like making it the same for nuget.exe and the dotnet packager .exe.
Sorry @ncook-vero, I mistook you for a project maintainer.
Perhaps one of the project maintainers can share some insight on this.
@adamralph I'm sure @dominoFire and/or someone else in the project team can clarify, but I would guess that:
Epic
for them, is anything that cannot fit in a single sprintYou are right. We make big features into epic and then split it into smaller work items that we can easily cost and implement within a short span of time, ideally a sprint. βBigβ can either mean big in terms of cost or complexity.
If it is an epic, can the epic be split into smaller stories that deliver usable functionality each sprint?
e.g: A support for 32x32 png icon only. No resize, nothing else. Not visible in NuGet on-line, but could be visible in our 3rd party browser.
This feature is shipping (with support in dotnet.exe pack and nuget.exe pack) in NuGet 5.3. The work that remains will be schedule for future releases. Closing the epic issue, so this properly shows up in 5.3 release notes.
Is there any code that you have (maybe in the .UI lib) that shows how you extract/display the icon in WPF? I'm trying implement it in NuGet Package Explorer.
Greatπ @onovotny seems bulk work is in this commit https://github.com/NuGet/NuGet.Client/commit/c05f9afa9c2fcee7fbe10754521b3f6424bee128
@devlead Unfortunately, that commit only handles packing/generating the package. We're already using the NuGet libraries to do that, so we're good there.
What I need is the proper extraction for binding in various scenarios (IconUrl, embeded Icon, etc).
Is it possible to refer to an image in a directory outside the project? It would be very useful to do so if you have multiple NuGet packages in a solution:
Root
Images
Icon.png
Source
Package1
Package1.csproj
Package2
Package2.csproj
<PropertyGroup Label="Package">
<!-- This is what I've tried: -->
<PackageIcon>file://../../Images/Icon.png</PackageIcon>
<PackageIcon>../../Images/Icon.png</PackageIcon>
</PropertyGroup>
<ItemGroup Label="Files">
<None Include="..\..\Images\Icon.png" Pack="true" PackagePath=""/>
</ItemGroup>
However, all I've tried so far produces errors.
UPDATE
I've figured it out. This seems to work:
<PropertyGroup Label="Package">
<PackageIcon>Icon.png</PackageIcon>
</PropertyGroup>
I think this was supported. @karann-msft would know better. And I saw the UPDATE after I typed π
Glad you found the right way.
The package path put the image in the root of the package. The package icon needs to refer to the matching location.
Please take a look at the docs and suggest any improvements that would help with this case.
After seeing this, I really wanted to package an icon in my NExpect
package(s). However, nuget pack
is bailing out with the error:
The element 'metadata' in namespace 'http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd' has invalid child element 'icon' in namespace 'http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd'. List of possible elements expected: 'requireLicenseAcceptance, licenseUrl, frameworkReferences, tags, repository, contentFiles, packageTypes, copyright, references, license, serviceable, developmentDependency, iconUrl, dependencies, frameworkAssemblies' in namespace 'http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd'. This validation error occurred in a 'icon' element.
My Package.nuspec
contains the following:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<package>
<metadata>
<id>NExpect</id>
<version>1.0.158</version>
<title>NExpect</title>
<authors>Davyd McColl</authors>
<owners>Davyd McColl</owners>
<description>



Unit-test Framework-agnostic Expect-style assertions for .NET



</description>
<releaseNotes>



</releaseNotes>
<summary>



Provides Expect() syntax for doing assertions in .NET. Framework-agnostic, throwing



UnmetExpectationExceptions for failures. Assertion exception type can be overridden at run-time.



NExpect has grammar inspired by Chai and extensibility inspired by Jasmine.



</summary>
<language>en-US</language>
<projectUrl>https://github.com/fluffynuts/NExpect</projectUrl>
<icon>icon.png</icon>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<license type="expression">BSD-3-Clause</license>
<copyright>Copyright 2017</copyright>
<dependencies>
<group targetFramework="net452"/>
</dependencies>
<references/>
<tags/>
</metadata>
<files>
<file src="icon.png" target="" />
<file src="bin\BuildForRelease\net452\NExpect.dll" target="lib\net452"/>
<file src="bin\BuildForRelease\net452\NExpect.pdb" target="lib\net452"/>
<file src="bin\BuildForRelease\netstandard2.0\NExpect.xml" target="lib\net452"/>
<file src="bin\BuildForRelease\netstandard2.0\NExpect.dll" target="lib\netstandard2.0"/>
<file src="bin\BuildForRelease\netstandard2.0\NExpect.xml" target="lib\netstandard2.0"/>
<file src="bin\BuildForRelease\netstandard2.0\NExpect.pdb" target="lib\netstandard2.0"/>
<file src="bin\BuildForRelease\netstandard2.0\NExpect.deps.json" target="lib\netstandard2.0"/>
</files>
</package>
what am I doing wrong?
@fluffynuts you need NuGet.exe version 5.3, guess it's not blessed yet, as it's not available on nuget ( https://www.nuget.org/packages/NuGet.CommandLine/ ).
But you can download it from https://www.nuget.org/downloads
Ah, thanks -- I did a nuget update -self
and got 5.2.something
; I'll try with 5.3, but I'll only really be able to switch over when 5.3 is blessed as build & release are automated, including nuget update -self
to ensure latest tooling at release.
Looks like our blessing we did of 5.3 missed a step. Weβll fix on Monday.
@fluffynuts are you unable to use dotnet pack
? The latest SDK contains the new icon bits.
@rrelyea - can you also please publish working nuspec.xsd's?
It would be nice to get some schema based intellisense in VS for nuspec files.
@adamralph whilst I'm in the process of converting to modern projects (Project Sdk
projects rather than ones mentioning toolsversion) where possible, I still have a bunch of legacy projects and afaik, dotnet <anything>
isn't going to work on them?
Anyways:
.vbproj
, and there is one in there)This hasn't stopped my release -- I just reference the icon by url from GitHub. I was just wanting to use the new mechanism seeing as I was in the neighborhood -- I just got an icon from an #hacktoberfest PR :+1:
@SimonCropp's comment has 17 upvotes (only π counts). GitHub doesn't have any way for us to transfer upvotes from one issue to another (let alone a comment from an issue). So, anyone interested please upvote this issue on adding SVG support (original/first comment, not my comment). At this time, that issue only has 3 upvotes (probably because it was closed years ago, but I just reopened it).
@zivkan - Can you make a feature request through official channels for that kind of thing? I would think it would be something you would have a better time requesting than the GenPop. If not or you dont want to wait, I imagine scripting something would be the way to aggregate votes across comments and issues for the same request.
only π counts
Lets not have any digital gerrymandering or "chads"; π β€οΈ π π and :Hooray: are all positive reactions and should all be counted as upvotes. Excluding them would be removing > 30% of the current votes.
Microsoft may have bought GitHub, but they still operate as an external company, and I have no inside knowledge or contacts. I don't even know where external customers can request new features.
Lets not have any digital gerrymandering or "chads"; π β€οΈ π π and :Hooray: are all positive reactions and should all be counted as upvotes. Excluding them would be removing > 30% of the current votes.
GitHub doesn't provide a way to sort issues by "all positive reactions", at least that I'm aware of. Therefore, while we prioritize work on a number of factors, on GitHub I look at open issues sorted by π , as that appears to be the most commonly used reaction. While it would be nice to count all positive reactions, we need to be pragmatic and it's something we can't easily take into account right now. If I'm wrong, I'd be happy for someone to educate me so we can better take all reactions into account.
I'd be happy for someone to educate me so we can better take all reactions into account.
For that specific comment...
$ErrorActionPreference = 'Stop'
$headers = @{"Accept"="application/vnd.github.squirrel-girl-preview+json";}
$url = "https://api.github.com/repos/NuGet/home/issues/comments/261106692/reactions"
$resp = Invoke-WebRequest -Headers $headers -Uri $url -UseBasicParsing
$rawResp = $resp.Content | ConvertFrom-Json
$rawResp | Group-Object -Property content | Sort-Object -Descending -Property Count | Format-Table -Property Count,Name
#####results####
Count Name
----- ----
17 +1
5 heart
2 hooray
1 laugh
I opened a ticket with GH support on how to do this through the UI, they said its currently not possible via the UI but forwarded the request to the product team with a link to the comment above by @zivkan explaining the need.
Is a side effect of this change that the Nuget package download now includes the icon file? We released a new version of our package using the new
If that is correct, is there a way to override this? A typical user for us wouldn't care if the nuget package manager properly shows the icon, but it's annoying for them to have our logo force its way into their project file structure. I would still want our package to have a logo on the Nuget Package Manager online search.
@rudyscoggins my package.nuspec
contains the line:
<file src="icon.png" target="" />
which I assume is the secret sauce for not having the icon deployed to the consumer (ie target=""
)
The icon will only appear in consuming projects if the package has been incorrectly created.
Ah, so I am doing something wrong. I'm not sure what though. I have the target=""...
Here's my nuspec file. Could you take a quick glance to see if something is wrong? The image lives at my project file root:
<?xml version="1.0"?>
<package >
<metadata>
<id>mySDK</id>
<version>20.96.2.1</version>
<title>mySDK 20.96</title>
<authors>Me</authors>
<owners>Me</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<icon>MyLogo.png</icon>
<description>Here's an SDK</description>
<summary>Here's a summary of the SDK</summary>
<releaseNotes>this is released</releaseNotes>
<copyright>Copyright 2020</copyright>
<license type="expression">Apache-2.0</license>
<tags>My SDK</tags>
<dependencies>
</dependencies>
</metadata>
<files>
<file src="MyLogo.png" target="" />
</files>
</package>
Are you creating your package with an explicit nuspec?
If possible, I advise moving away from that and allowing the SDK to create the nuspec for you. FWIW, I just have a PackageIcon
element in my csproj and the rest Just Works. β https://github.com/adamralph/bullseye/blob/d11fea517642b5f56f19d5a6963f4a818b698cc9/Bullseye/Bullseye.csproj#L11
If I dig into the nupkg
, the generated nuspec
looks like this:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>Bullseye</id>
<version>3.7.0</version>
<authors>Bullseye</authors>
<owners>Bullseye</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<license type="expression">Apache-2.0</license>
<licenseUrl>https://licenses.nuget.org/Apache-2.0</licenseUrl>
<projectUrl>https://github.com/adamralph/bullseye</projectUrl>
<description>Runs a target dependency graph.</description>
<releaseNotes>https://github.com/adamralph/bullseye/blob/master/CHANGELOG.md</releaseNotes>
<repository type="git" url="https://github.com/adamralph/bullseye" commit="89fc1b57063c44e21bc851f218f166ca63a6e846" />
<dependencies>
<group targetFramework=".NETStandard2.0" />
</dependencies>
<icon>bullseye.png</icon>
</metadata>
</package>
Note that there is no file
element for the icon file. It's file is just sitting in the root folder in the nupkg
archive.
Oh, there is also this β https://github.com/adamralph/bullseye/blob/d11fea517642b5f56f19d5a6963f4a818b698cc9/Bullseye/Bullseye.csproj#L26 β so I guess it's not quite as simple as it could be.
Thanks all for the help and sanity checks! I really appreciate it and it helped me solve the problem.
Turns out I thought I needed to include the image file in the project. After experimenting, I realized it SHOULDN'T be included in the project and is only meant to reside in the nuget package. This is what caused it to be distributed. Hopefully this helps someone else.
@adamralph my upload process needs to be revised, relying more on self made scripts than nuget standards. I'll incorporate your suggestion for moving more into the SDK. Thanks!
This puts the burden on the developer to find a place to host those files and update the NuSpec with their locations.
I don't get it. What kind of burden is this? If you want to update an icon you would update it one place... Now I actually do need to specify the icon anyway and copy the icon to every project which suppose to be packed and make sure the icon have the same version in all those places... Is this a less burden? What kind of improvement is this?
If you really need the icon to be embedded, why not just download the icon form the iconUrl
and place it in the package during pack, instead of the "'iconUrl' element is deprecated..." nonsense?
@PawcioCNCProfi
why not just download the icon form the iconUrl and place it in the package during pack
because that would be a breaking change. ie for anyone expecting the old behavior of being able to change the icon at the target url and have the package be rendered with the new icon
Package Icon should be able to come form inside the package. It should be possible to put a path in the iconUrl that is relative to the package.