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

Unable to use Microsoft.AspNetCore.App/All metapackage with FAKE #1991

Closed
kblohm opened this issue Jun 10, 2018 · 5 comments
Closed

Unable to use Microsoft.AspNetCore.App/All metapackage with FAKE #1991

kblohm opened this issue Jun 10, 2018 · 5 comments

Comments

@kblohm
Copy link
Contributor

kblohm commented Jun 10, 2018

Description

I can not reference the Microsoft.AspNetCore.App metapackage and use it in my build.fsx when running it with FAKE. I can however run the script in FSI.

Repro steps

  1. Use the following paket.dependencies
// [ FAKE GROUP ]
group Build
    source https://api.nuget.org/v3/index.json
    nuget Fake.Core.Target
    nuget Microsoft.AspNetCore.App
  1. Use the following build.fsx
#load ".fake/build.fsx/intellisense.fsx"

// let execContext = Fake.Core.Context.FakeExecutionContext.Create false "build.fsx" []
// Fake.Core.Context.setExecutionContext (Fake.Core.Context.RuntimeContext.Fake execContext)
open Fake.Core
open Microsoft.AspNetCore.Builder
open Microsoft.AspNetCore.Hosting

Target.create "Dummy" (fun _ ->
    ()
)
Target.runOrDefault "Dummy"

run fake build. This does not seem to work. If you uncomment the fakeContext-stuff and run it in FSI, everything is fine. Is this just me or is this a bug?

Workaround

Reference packages directly

// [ FAKE GROUP ]
group Build
    source https://api.nuget.org/v3/index.json
    nuget Fake.Core.Target
    nuget Microsoft.AspNetCore
    nuget Microsoft.AspNetCore.Hosting
@matthid
Copy link
Member

matthid commented Jun 10, 2018

Another instance of:

Basically fake uses netstandard2.0 as framework moniker and not netcoreapp - maybe we can indeed change that but I have no idea what other side-effects that has.

@kblohm
Copy link
Contributor Author

kblohm commented Jun 10, 2018

Ahh, that is inconvenient. So the workaround is pretty much what i am doing now, at least until we can maybe think of something more clever?

@matthid
Copy link
Member

matthid commented Jun 10, 2018

No it seems to be by design that you can explicitly not use that package in a library setting (which even makes sense) and currently we consider the script to be a "library" loaded by the fake runtime (which is technically what happens)

@matthid
Copy link
Member

matthid commented Jun 10, 2018

Or in other words I'm not quite ready to do hacks in paket or fake just for that package ;)

@kblohm
Copy link
Contributor Author

kblohm commented Jun 10, 2018

I read the other issues, that makes sense. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants