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.

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

Fat Portable apps not publishing native assets. #559

Closed
ramarag opened this issue Dec 28, 2016 · 3 comments
Closed

Fat Portable apps not publishing native assets. #559

ramarag opened this issue Dec 28, 2016 · 3 comments
Assignees
Labels
Milestone

Comments

@ramarag
Copy link
Member

ramarag commented Dec 28, 2016

If we publish a fat portable app, we expect the rids specified in the project to be published under rid split folders in the app bin directory.

This bug is present in both project.json based cli and msbuild based cli

dotnet --info

.NET Command Line Tools (1.0.0-preview2-003133)

Product Information:
 Version:            1.0.0-preview2-003133
 Commit SHA-1 hash:  74df06500c

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x86

cc @schellap @gkhanna79 @livarcocc @nguerrera @dsplaisted @eerhardt @piotrpMSFT @srivatsn

Sample project.json :

  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable",
    "emitEntryPoint": true
  },
  "dependencies": { 
      "Microsoft.NETCore.CoreDisTools": "1.0.1-prerelease-00001",
  "System.Runtime.Serialization.Json": "4.4.0-beta-24821-02"},
  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.1"
        }
      },
      "imports": "dnxcore50"
    }
  },
"runtimes": {
    "win7-x86": {},
    "win7-x64": {},
    "ubuntu.14.04-x64": {},
    "osx.10.10-x64": {},
    "centos.7-x64": {},
    "rhel.7-x64": {},
    "debian.8-x64": {}
  }
@srivatsn srivatsn modified the milestones: 2.0, 1.0 RTM Dec 28, 2016
@srivatsn srivatsn added the Bug label Dec 28, 2016
@nguerrera
Copy link
Contributor

@ramarag Please clarify with full repro steps and spell out which files you expect to be somewhere that aren't.

@ramarag
Copy link
Member Author

ramarag commented Jan 25, 2017

when the app is published:

bin\debug<tfm>\publish<managed_assets>
bin\debug<tfm>\publish<rid><native_assets>

that is
bin\debug<tfm>\publish\win7-x64\coredistools.dll
bin\debug<tfm>\publish\ubuntu.14.04-x64\libcoredistool.so
bin\debug<tfm>\publish\osx.10.10-x64\libcoredistool.dylib
bin\debug<tfm>\publish\centos.7-x64\libcoredistool.so
bin\debug<tfm>\publish\rhel.7-x64\libcoredistool.so
bin\debug<tfm>\publish\debian.8-x64\libcoredistool.so

@srivatsn srivatsn modified the milestones: 2.0, 1.0 RTM Jan 26, 2017
@livarcocc livarcocc modified the milestones: 2.0.0, 2.1.0 May 27, 2017
@livarcocc livarcocc modified the milestones: 2.1.0, 15.5 Oct 4, 2017
@nguerrera
Copy link
Contributor

This works already. Native assets go to publish\<rid>\native\

mmitche pushed a commit to mmitche/sdk that referenced this issue Jun 5, 2020
erikbra added a commit to erikbra/dotnet-sdk that referenced this issue May 9, 2024
…RYPOINT for Self Contained Builds

* Fixed existing integration test that tested that ContainerEntryPoint can be deferred
  (it wasn't actually testing anything, due to a bug in the test)
* Changed the test to test that we defer ContainerAppCommand instead
  (ContainerEntryPoint is not deferred anymore on .net 8)
* Added runtime identifier dimension to the test (linux vs windows)
* Fixed integration test ProjectInitializer to take into account Windows vs *nix
  when setting executable extension (.exe or nothing)
* Fixed Microsoft.NET.Build.Containers.targets so that the behaviour is as expected on
  both Windows and linux containers
erikbra added a commit to erikbra/dotnet-sdk that referenced this issue May 9, 2024
…RYPOINT for Self Contained Builds

* Fixed existing integration test that tested that ContainerEntryPoint can be deferred
  (it wasn't actually testing anything, due to a bug in the test)
* Changed the test to test that we defer ContainerAppCommand instead
  (ContainerEntryPoint is not deferred anymore on .net 8)
* Added runtime identifier dimension to the test (linux vs windows)
* Fixed integration test ProjectInitializer to take into account Windows vs *nix
  when setting executable extension (.exe or nothing)
* Fixed Microsoft.NET.Build.Containers.targets so that the behaviour is as expected on
  both Windows and linux containers
erikbra added a commit to erikbra/dotnet-sdk that referenced this issue May 9, 2024
…RYPOINT for Self Contained Builds

* Fixed existing integration test that tested that ContainerEntryPoint can be deferred
  (it wasn't actually testing anything, due to a bug in the test)
* Changed the test to test that we defer ContainerAppCommand instead
  (ContainerEntryPoint is not deferred anymore on .net 8)
* Added runtime identifier dimension to the test (linux vs windows)
* Fixed integration test ProjectInitializer to take into account Windows vs *nix
  when setting executable extension (.exe or nothing)
* Fixed Microsoft.NET.Build.Containers.targets so that the behaviour is as expected on
  both Windows and linux containers
erikbra added a commit to erikbra/dotnet-sdk that referenced this issue May 10, 2024
…RYPOINT for Self Contained Builds

* Fixed existing integration test that tested that ContainerEntryPoint can be deferred
  (it wasn't actually testing anything, due to a bug in the test)
* Changed the test to test that we defer ContainerAppCommand instead
  (ContainerEntryPoint is not deferred anymore on .net 8)
* Added runtime identifier dimension to the test (linux vs windows)
* Fixed integration test ProjectInitializer to take into account Windows vs *nix
  when setting executable extension (.exe or nothing)
* Fixed Microsoft.NET.Build.Containers.targets so that the behaviour is as expected on
  both Windows and linux containers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants