ProjectReferences that are executables don't get an apphost on SCD publish

[damageboy]

When I publish/SCD project A that has a dependency on project B (both projects being netcoreapp2.1 executables / console applications), I get a pair of A.dll, A.exe (assembly + apphost), but unfortunately, while I do get a published B.dll and I could issue dotnet B.dll to run it, I don't get a B.exe apphost published alongside it.

I've written, for my own hacky purposes, a python script to generate the apphost exectuable (after copy pasting and translating the code from c# to a few python lines), and for what it's worth, I can testify that all that is missing is simply the creation of the apphost executable and nothing more.

The use case for this is for people wanting to publish a major application (being the project A in my example) with a few additional ancillary tools (project B, in my example) as one big happy .zip / tarball for end users.

As I've stated before, I hacked my way into getting this functionality by manually generating the app hosts on Windows/Linux/OSX with a python script, but I feel it is worthwhile to have this discussion here to see if this is a sort of end-user scenario that the sdk should support out of the box, especially given the relatively little amount of work I feel it should entail...

[peterhuene]

Hi @damageboy,

Thanks for the feedback! Would publishing A and B independently and then copy what is needed into a single location or, alternatively, publish both projects (sans P2P reference) to the same output directory work at all?

If possible, I would avoid using P2P references from Exe output type projects since there are a number of known issues there regarding publishing and, thus far, the majority of users that run into those problems are using test projects that inadvertently publish when publishing a solution (i.e. they don't want these projects published anyway). To the best of my knowledge, we haven't had users request support for publishing P2P Exe references and expecting multiple apphosts from a single publish operation before.

However, we are looking at improving publishing for 3.0 and I would like to better my understanding of your scenario to see if there's something we can make work for you.

[damageboy]

I'll try and walk you through the different options I've tried, but I preface this by saying I really don't know if what I'm offering here is anything more than an ultra niche end-case which shouldn't really interest anyone beyond me and my team :)

Ultimately I though it would be a good idea to post this issue to see if there is any interest in this outside of my case.

Back to the matter at hand:

Would publishing A and B independently and then copy what is needed into a single location or, alternatively, publish both projects (sans P2P reference) to the same output directory work at all?

I already gave that a try, and this runs into a wall pretty quickly with transitive dependencies: When I publish different netcoreapp2.1 projects independently and then try to mash them together in any of the methods you have suggested, I end up getting what I call heisen-deps: where, to take a relevant example, project A would reference (transitively) System.ComponentModel.Annotations.dll version X, while project B would resolve to using version Y, due to having different paths to their transitive dpendency. This ends up exploding randomly according to build order.

The reason I find this somewhat useful, is that:

1. It works (including my apphost python script, that is)
2. It generates relatively small SCD deployments that I can zip up and have users download quickly:
   If my different netcoreapp2.1 projects have a lot of heavy dependencies (in MBs) that are duplicated, with multiple deployments, this method actually keeps the size reasonably down
3. When later crossgen-ing the resulting .dll, I get the job done more quickly
4. I don't end up having different transitive dependencies depending on which .exe I'm packaging: All of my project that have a transitive dependency on System.ComponentModel.Annotations.dll are using the same version, which leads to easier reasoning when it comes to dealing with issues.

That's it, all I'm saying that for packaging 10-20 executables that are all coming from a single code-base, I can't seem to think of a better approach when considering all the options.

I fully acknowledge that without having more people asking for this, its better for everyone if I keep doing my hack, and leave it there.

But I would like thsi to stay open for a while in case someone who is not me finds this interesting / needed...

Does that make sense?

[peterhuene]

I think it might make some sense to generate an apphost for P2P exe references, so I'll see what I can do to improve this experience for 3.0; there's a few other problems in that space I'd also like to solve.

[dsplaisted]

I believe this will be fixed in .NET SDK 5.0.200 via this PR: #14488