Skip to content

Question: How to configure project to always build as a "standalone app" #442

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

Closed
mellinoe opened this issue Nov 30, 2016 · 7 comments
Closed
Assignees
Labels
Milestone

Comments

@mellinoe
Copy link
Contributor

I'm looking at what it will take to port some of my projects onto the new SDK. My projects are already MSBuild-based, and just use a small set of properties and targets to get references, configurations, output paths, etc. consistent. For most of my projects, I'm really only interested in building things fully standalone (i.e. never as a portable/shared framework app). Is there an easy way that I can set up my projects with the new tooling to accomplish this? Ideally, whenever I built an executable project, all of my runtime dependencies from nuget would be copied next to my project output. Essentially, I'm looking for something similar to how the regular MSBuild targets handle <CopyNuGetImplementations>true</CopyNuGetImplementations>.

@mellinoe mellinoe changed the title Question: Set up project to always build as a "standalone app" Question: How to configure project to always build as a "standalone app" Nov 30, 2016
@dsplaisted
Copy link
Member

I think you just need to set the RuntimeIdentifier property.

@mellinoe
Copy link
Contributor Author

Setting RuntimeIdentifier doesn't seem to do what I want. First, it fails to build all of my ProjectReference's, I guess because they don't have any RuntimeIdentifier items defined (because they're libraries).

If I do it on a project created from the template (dotnet new), it still just builds a portable app. The only difference is the deps.json is much larger when I specify RuntimeIdentifier.

@dsplaisted
Copy link
Member

I experimented a bit and this is what worked for me for a basic console app:

dotnet restore /p:RuntimeIdentifier=win7-x86
dotnet publish -r win7-x86

I'm not sure about why it wouldn't be building project references for you.

@mellinoe
Copy link
Contributor Author

mellinoe commented Nov 30, 2016

The ProjectReference issue seems to be reproducible by just creating a console app and a class library (via dotnet new) and then referencing the library from the app. The class library fails to compile; it's not able to resolve any references.

I'm aware that the Publish target does roughly what I'm after. I was wondering how I could configure my project in such a way that "publishing standalone" was the default behavior, since that's how my projects currently behave. I think doing something like this gets me close:

<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build;Publish">
  <PropertyGroup><RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == ''">win7-x64</RuntimeIdentifier></PropertyGroup>
...

@srivatsn srivatsn added the Bug label Dec 15, 2016
@srivatsn srivatsn added this to the 1.0 RC3 milestone Dec 15, 2016
@dsplaisted
Copy link
Member

Turns out we have documentation for this (thanks to @nguerrera for pointing it out on #450).

I think you may need to set the RuntimeIdentifiers property for NuGet and the RuntimeIdentifier property for the Publish target.

@natemcmaster
Copy link
Contributor

natemcmaster commented Jan 12, 2017

Just ran into this as well. Is there anyway that users can write this kind of logic in their project?

<PropertyGroup>
    <RuntimeIdentifier>$(CurrentRid)</RuntimeIdentifer>
</PropertyGroup>

This way 'dotnet publish' always publishes as standalone for the current platform, without having to add '-r $rid'.

@mellinoe
Copy link
Contributor Author

Yes, +1 to @natemcmaster 's question. Can we have an MSBuild property exposed for that? I know we would find something like that very useful in corefx, as well.

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