[create-vsix] Ensure registration shows up in Help/About#614
Merged
jonpryor merged 2 commits intodotnet:masterfrom May 31, 2017
kzu:vsix-registration
Merged
[create-vsix] Ensure registration shows up in Help/About#614jonpryor merged 2 commits intodotnet:masterfrom kzu:vsix-registration
jonpryor merged 2 commits intodotnet:masterfrom
kzu:vsix-registration
Conversation
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=56867 It turns out that having a *package* definition in the pkgdef without a corresponding Package entry in the same file, makes it impossible for VS to find the associated resources with the given IDs (#400 for the icon, #110 and #112 for the name and description). It also turns out that even if were to do without the icon, using plain strings for #110/112 doesn't work either, and the package entry has to be there anyway, alongside the assembly and code base. Therefore, just add it to the VSIX payload so that VS can use it to locate those resources for Help/About and nothing else. Since we still tell the VSSDK targets *not* to create the PKGDEF from the Package-derived class, this should still mean it's a plain IL compilation for xbuild/MacOSX and hopefully it won't break anything. NOTE: the AssemblyName has to match what's in the PKGDEF, so we made it match with the official one too. Since this assembly name isn't used for anything at run-time, it's fine to leave it as-is with no changes. The new gazillion packages/references are needed just so the AndroidSdkPackage class can inherit from Package as expected by VS.
jonpryor
reviewed
May 31, 2017
| <OutputType>Library</OutputType> | ||
| <RootNamespace>Xamarin.Android.Sdk</RootNamespace> | ||
| <AssemblyName>Xamarin.Android.Sdk-OSS</AssemblyName> | ||
| <AssemblyName>Xamarin.Android.Sdk</AssemblyName> |
Contributor
There was a problem hiding this comment.
Since $(AsemblyName) is changed, this should also change the _GetVsixPath target in create-vsix.targets to re-add -OSS
<VsixPath Condition=" '$(VsixPath)' == '' ">..\..\bin\Build$(Configuration)\$(AssemblyName)-OSS-$(ProductVersion).$(XAVersionCommitCount)_$(XAVersionBranch)_$(XAVersionHash).vsix</VsixPath>The reason for this is so that you can sanely download both commercial and OSS .vsix files into the same directory without fearing for filename collisions.
Contributor
Author
There was a problem hiding this comment.
I assume that on the commercial build that property will be set to the non-OSS suffixed version?
Contributor
There was a problem hiding this comment.
Correct, the commercial build overrides the $(VsixPath) property.
jonpryor
pushed a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 5, 2017
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=56867 It turns out that having a *package* definition in the pkgdef without a corresponding Package entry in the same file, makes it impossible for VS to find the associated resources with the given IDs (dotnet#400 for the icon, dotnet#110 and dotnet#112 for the name and description). It also turns out that even if were to do without the icon, using plain strings for dotnet#110/112 doesn't work either, and the package entry has to be there anyway, alongside the assembly and code base. Therefore, just add it to the VSIX payload so that VS can use it to locate those resources for Help/About and nothing else. Since we still tell the VSSDK targets *not* to create the PKGDEF from the Package-derived class, this should still mean it's a plain IL compilation for xbuild/MacOSX and hopefully it won't break anything. NOTE: the AssemblyName has to match what's in the PKGDEF, so we made it match with the official one too. Since this assembly name isn't used for anything at run-time, it's fine to leave it as-is with no changes. The new gazillion packages/references are needed just so the AndroidSdkPackage class can inherit from Package as expected by VS.
jonpryor
pushed a commit
that referenced
this pull request
Jun 6, 2017
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=56867 It turns out that having a *package* definition in the pkgdef without a corresponding Package entry in the same file, makes it impossible for VS to find the associated resources with the given IDs (#400 for the icon, #110 and #112 for the name and description). It also turns out that even if were to do without the icon, using plain strings for #110/112 doesn't work either, and the package entry has to be there anyway, alongside the assembly and code base. Therefore, just add it to the VSIX payload so that VS can use it to locate those resources for Help/About and nothing else. Since we still tell the VSSDK targets *not* to create the PKGDEF from the Package-derived class, this should still mean it's a plain IL compilation for xbuild/MacOSX and hopefully it won't break anything. NOTE: the AssemblyName has to match what's in the PKGDEF, so we made it match with the official one too. Since this assembly name isn't used for anything at run-time, it's fine to leave it as-is with no changes. The new gazillion packages/references are needed just so the AndroidSdkPackage class can inherit from Package as expected by VS.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Mar 30, 2020
Changes: dotnet/java-interop@56c92c7...d70e40f * dotnet/java-interop@d70e40f1: [Java.Interop, jnienv-gen] Add netcoreapp3.1 support (dotnet#614)
jonpryor
added a commit
that referenced
this pull request
Mar 31, 2020
Changes: dotnet/java-interop@56c92c7...d70e40f * dotnet/java-interop@d70e40f1: [Java.Interop, jnienv-gen] Add netcoreapp3.1 support (#614)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=56867
It turns out that having a package definition in the pkgdef
without a corresponding Package entry in the same file, makes
it impossible for VS to find the associated resources with the
given IDs (#400 for the icon, #110 and #112 for the name and
description).
It also turns out that even if were to do without the icon,
using plain strings for #110/112 doesn't work either, and the
package entry has to be there anyway, alongside the assembly
and code base.
Therefore, just add it to the VSIX payload so that VS can use
it to locate those resources for Help/About and nothing else.
Since we still tell the VSSDK targets not to create the PKGDEF
from the Package-derived class, this should still mean it's a
plain IL compilation for xbuild/MacOSX and hopefully it won't
break anything.
NOTE: the AssemblyName has to match what's in the PKGDEF, so
we made it match with the official one too. Since this assembly
name isn't used for anything at run-time, it's fine to leave it
as-is with no changes.
The new gazillion packages/references are needed just so the
AndroidSdkPackage class can inherit from Package as expected
by VS.