3 ms·

Here you go: <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net6.0</TargetFramework> <Nullable>enable</Nullable>

Here you go: <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net6.0</TargetFramework> <Nullable>enable</Nullable> <ImplicitUsings>enable</ImplicitUsings> <OutputType>exe</OutputType> </PropertyGroup> <ItemGroup> <FrameworkReference Include="Microsoft.AspNetCore.App" /> </ItemGroup> </Project> Just create an empty ASP.NET Core project, change the SDK, add a FrameworkReference and a OutputType. Read the console args and configure the web app with a port as desired.

luuio 5y ago
Thanks! This is what I was looking for (not anymore, sorry switched to a different language/ecosystem for this project). This still begs the question, or my original point still stands—why framework reference vs. nuget reference? I'm sure there's a perfectly rationale explanation, but this in itself, having at least two "official" ways of managing dependencies (framework reference vs. package reference on nuget), it's kind of a "code smell" imo.
- JamesNK 5y ago
  Because ASP.NET Core is a framework that is installed with .NET. It isn’t a set of Nuget packages. Why? .NET Core 1.x tried making everything a Nuget package and it was a disaster. ASP.NET is big which meant a huge number of dependencies, easy to create conflicts, long restore and build times. It was much better to just include ASP.NET Core in the box with .NET and simplify it down to a single reference. And most people use the web SDK which does it for you so they don't even need that.
  - luuio 5y ago
    What about the option to just make everything asp.net one single nuget package? And how come other ecosystems/languages don't have this issue? What's the difference? The other question is, why isn't what you posted the default, but defaulting to this <Project Sdk=...>? To me, it's a lot more intuitive, signaling that each project can have multiple framework references, vs. just one SDK attribute.
    - JamesNK 5y ago
      You're searching for ways to make things more difficult than they need to be. Make the simple easy. Make the complex possible.
      - luuio 5y ago
        Disagree here. This is where I would quote the principles of two other language. From Python: have one way of doing things From Go: explicit is bette than implicit. Is Sdk=... is just a short cut to pull in a handful of framework references? Or are there actually more things happening under the hood? https://news.ycombinator.com/item?id=30673710 https://news.ycombinator.com/item?id=30673710
        dahauns 5y ago
        sigh I can't help it... Python really isn't a great choice for making your case. "Have one obvious way of doing things" has become an ironic meme since forever, and toolchaining and dependency management has traditionally been a hot mess (yes, even with pip and virtualenv, just not the total clusterfudge it was before. And don't get me started on pipenv.), and only gotten better recently with 3rd party tools like poetry, or even conda.
    - dahauns 5y ago
      >What about the option to just make everything asp.net one single nuget package? And how come other ecosystems/languages don't have this issue? What's the difference? It's no different to e.g. create-react-app vs npm install react.

luuio 5y ago

Thanks! This is what I was looking for (not anymore, sorry switched to a different language/ecosystem for this project). This still begs the question, or my original point still stands—why framework reference vs. nuget reference? I'm sure there's a perfectly rationale explanation, but this in itself, having at least two "official" ways of managing dependencies (framework reference vs. package reference on nuget), it's kind of a "code smell" imo.

JamesNK 5y ago
Because ASP.NET Core is a framework that is installed with .NET. It isn’t a set of Nuget packages. Why? .NET Core 1.x tried making everything a Nuget package and it was a disaster. ASP.NET is big which meant a huge number of dependencies, easy to create conflicts, long restore and build times. It was much better to just include ASP.NET Core in the box with .NET and simplify it down to a single reference. And most people use the web SDK which does it for you so they don't even need that.
- luuio 5y ago
  What about the option to just make everything asp.net one single nuget package? And how come other ecosystems/languages don't have this issue? What's the difference? The other question is, why isn't what you posted the default, but defaulting to this <Project Sdk=...>? To me, it's a lot more intuitive, signaling that each project can have multiple framework references, vs. just one SDK attribute.
  - JamesNK 5y ago
    You're searching for ways to make things more difficult than they need to be. Make the simple easy. Make the complex possible.
    - luuio 5y ago
      Disagree here. This is where I would quote the principles of two other language. From Python: have one way of doing things From Go: explicit is bette than implicit. Is Sdk=... is just a short cut to pull in a handful of framework references? Or are there actually more things happening under the hood? https://news.ycombinator.com/item?id=30673710 https://news.ycombinator.com/item?id=30673710
      - dahauns 5y ago
        sigh I can't help it... Python really isn't a great choice for making your case. "Have one obvious way of doing things" has become an ironic meme since forever, and toolchaining and dependency management has traditionally been a hot mess (yes, even with pip and virtualenv, just not the total clusterfudge it was before. And don't get me started on pipenv.), and only gotten better recently with 3rd party tools like poetry, or even conda.
  - dahauns 5y ago
    >What about the option to just make everything asp.net one single nuget package? And how come other ecosystems/languages don't have this issue? What's the difference? It's no different to e.g. create-react-app vs npm install react.