-
Notifications
You must be signed in to change notification settings - Fork 526
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LICENSE] Add the libzip license. #112
Merged
Merged
Conversation
This file contains 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
kzu
added a commit
to kzu/xamarin-android
that referenced
this pull request
May 30, 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.
kzu
added a commit
to kzu/xamarin-android
that referenced
this pull request
May 30, 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.
kzu
added a commit
to kzu/xamarin-android
that referenced
this pull request
May 30, 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.
kzu
added a commit
to kzu/xamarin-android
that referenced
this pull request
May 30, 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
May 31, 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
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.
radical
pushed a commit
that referenced
this pull request
May 8, 2018
Properly use `nunit.framework.dll` from NuGet packages. Mono 4.9 changes `nunit.framework.dll` so that all types and members are `[Obsolete(IsError=true)]`, i.e. referencing them results in e.g.: GrefsTest.cs(12,3): error CS0619: `NUnit.Framework.TestFixtureAttribute' is obsolete: `The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.' Some project files were properly using the NuGet package, but not all of them. Fix all of the project files so that the NuGet package's `nunit.framework.dll` is correctly used. Additionally, set `$(DebugType)` to `Full` in `TestJVM.csproj`, to work around a [Roslyn bug][0]. [0]: https://bugzilla.xamarin.com/show_bug.cgi?id=51175
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Mar 25, 2021
Fixes: https://developercommunity.visualstudio.com/t/illegal-character-exception-in-xamarinandroid-afte/1363149 Changes: dotnet/android-tools@554d45a...237642c * dotnet/android-tools@237642c: [Xamarin.Android.Tools.AndroidSdk] Probe for Microsoft OpenJDK dirs (dotnet#113) * dotnet/android-tools@e618e00: [Xamarin.Android.Tools.AndroidSdk] Fix quotes in %PATH% or %PATHEXT% (dotnet#112)
jonpryor
added a commit
that referenced
this pull request
Mar 25, 2021
Fixes: https://developercommunity.visualstudio.com/t/illegal-character-exception-in-xamarinandroid-afte/1363149 Changes: dotnet/android-tools@554d45a...237642c * dotnet/android-tools@237642c: [Xamarin.Android.Tools.AndroidSdk] Probe for Microsoft OpenJDK dirs (#113) * dotnet/android-tools@e618e00: [Xamarin.Android.Tools.AndroidSdk] Fix quotes in %PATH% or %PATHEXT% (#112)
jonpryor
pushed a commit
that referenced
this pull request
Aug 26, 2022
…7309) Changes: mono/mono.posix@e1269a5...d8994ca * mono/mono.posix@d8994ca: Remove Windows support completely for now Fixes an issue in which Mono.Unix would try to resolve `libc` P/Invokes by looking for the `msvcrt` library on Unix machines. * mono/mono.posix@74d504f: Fix yaml template path * mono/mono.posix@127cf9e: [build] Don't rebuild managed code on packaging time on Windows Changes: dotnet/android-libzipsharp@2.0.4...2.0.7 * dotnet/android-libzipsharp@98e9173: Bump version to 2.0.7 * dotnet/android-libzipsharp@6e1e1b3: Localized file check-in by OneLocBuild Task: Build definition ID 11678: Build ID 6581869 (#119) * dotnet/android-libzipsharp@1c05430: LEGO: Merge pull request 118 * dotnet/android-libzipsharp@06d44d8: Localized file check-in by OneLocBuild Task: Build definition ID 11678: Build ID 6570668 (#117) * dotnet/android-libzipsharp@37f3894: LEGO: Merge pull request 116 * dotnet/android-libzipsharp@6c0edc5: Update libzip and zlib submodules (#115) * dotnet/android-libzipsharp@acd9a54: [Localization] Switch from xlf to resx files (#112) * dotnet/android-libzipsharp@3cece80: LEGO: Merge pull request 114 * dotnet/android-libzipsharp@fe336b4: LEGO: Merge pull request 113 * dotnet/android-libzipsharp@9aee99a: [Localization] Add OneLocBuild job (#111) * dotnet/android-libzipsharp@bdfa9f8: Bump Mono.Unix to 7.1.0-final.1.21458.1 (#110) Changes: xamarin/monodroid@210073e...100ccf9 * xamarin/monodroid@100ccf969: Bump to xamarin/androidtools@81486ab, xamarin/android-sdk-installer@8cac7ea (#1264) Changes: dotnet/android-tools@9c641b3...29f11f2 * dotnet/android-tools@29f11f2 Bump to mono/mono.posix@d8994ca, dotnet/android-libzipsharp@98e9173 (#193) * dotnet/android-tools@7cfe683 [ci] Use Microsoft.SourceLink.GitHub (#192) * dotnet/android-tools@01a0dde [Localization] Import translated resx files (#189) * dotnet/android-tools@cc715d9 [Xamarin.Android.Tools.AndroidSdk] Permit NDK r25 (#190) * dotnet/android-tools@3c55e9a Avoid `Environment.SpecialFolder.ApplicationData` (#188) * dotnet/android-tools@0d55472 LEGO: Merge pull request 187 * dotnet/android-tools@6946512 Juno: check in to juno/hb_befb220e-87ce-47e9-a9e6-10ea592b2337_20220729154833425. (#186) * dotnet/android-tools@6e3433a Juno: check in to juno/hb_befb220e-87ce-47e9-a9e6-10ea592b2337_20220729025332507. (#185) * dotnet/android-tools@73c4388 [Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-33 (#184) * dotnet/android-tools@da3653e [Xamarin.Android.Tools.AndroidSdk] Add API-33 to KnownVersions * dotnet/android-tools@327d433 [ci] Run OneLocBuild on a schedule (#180) * dotnet/android-tools@8ab60e4 [ci] Use latest macOS and Windows images (#181) * dotnet/android-tools@4dd3292 LEGO: Merge pull request 182 * dotnet/android-tools@56b61f1 [Localization] Add OneLocBuild job (#175) * dotnet/android-tools@14076a6 [Xamarin.Android.Tools.AndroidSdk] Add API-32 to KnownVersions
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
No description provided.