Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Fix a pathing issue when creating the Proguard Input Jar #110

Merged
merged 1 commit into from
Jul 8, 2016
Merged

Fix a pathing issue when creating the Proguard Input Jar #110

merged 1 commit into from
Jul 8, 2016

Conversation

dellis1972
Copy link
Contributor

The switch over to using LibZipSharp means that the API
to ZipArchive.AddFile slightly changed. Wtih Ionic.Zip
you just needed to provide the target Directory in the zip.
With LibZipSharp you need to provide the full path in the
zip including the filename.

This commit fixes that issue.

@dellis1972
Fix a pathing issue when creating the Proguard Input Jar
2a0efcf 
The switch over to using LibZipSharp means that the API
to ZipArchive.AddFile slightly changed. Wtih Ionic.Zip
you just needed to provide the target Directory in the zip.
With LibZipSharp you need to provide the full path in the
zip including the filename.

This commit fixes that issue.
@atsushieno atsushieno merged commit 02913d7 into dotnet:master Jul 8, 2016
kzu added a commit to kzu/xamarin-android that referenced this pull request May 30, 2017
@kzu
[create-vsix] Ensure registration shows up in Help/About
f20e800 
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
@kzu
[create-vsix] Ensure registration shows up in Help/About
219ee12 
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
@kzu
[create-vsix] Ensure registration shows up in Help/About
0ad10dd 
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
@kzu
[create-vsix] Ensure registration shows up in Help/About
8490627 
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.
@kzu kzu mentioned this pull request May 30, 2017
Merged
jonpryor pushed a commit that referenced this pull request May 31, 2017
@kzu @jonpryor
[create-vsix] Ensure registration shows up in Help/About (#614)
4372184 
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
@kzu @jonpryor
[create-vsix] Ensure registration shows up in Help/About (dotnet#614)
c335d6c 
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
@kzu @jonpryor
[create-vsix] Ensure registration shows up in Help/About (#614)
0976f75 
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 9, 2021
@jonpryor
Bump to xamarin/xamarin-android-tools/d16-9@d210f11f
43851a5 
Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1277223

Changes: dotnet/android-tools@9d8924d...d210f11

  * xamarin/xamarin-android-tool@d210f11: [macOS] fix DirectoryNotFoundException on clean systems (dotnet#110)
@jonpryor jonpryor mentioned this pull request Mar 9, 2021
Merged
jonpryor added a commit that referenced this pull request Mar 10, 2021
@jonpryor
Bump to xamarin/xamarin-android-tools/d16-9@d210f11f (#5721)
b72993a 
Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1277223

Changes: dotnet/android-tools@9d8924d...d210f11

  * xamarin/xamarin-android-tool@d210f11: [macOS] fix DirectoryNotFoundException on clean systems (#110)
jonpryor pushed a commit that referenced this pull request Aug 26, 2022
@grendello
Bump to mono/mono.posix@d8994ca, dotnet/android-libzipsharp@98e9173 (#…
91f330f 
…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
@github-actions github-actions bot locked and limited conversation to collaborators Feb 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@dellis1972 @atsushieno @dnfclas