NET Core and ASP.NET Core RC2 Released

Dunno, restarted my Mac - still not working. Running latest version - 10.11.5

a mounted volume and possibly using dotnet-watch within the actual container may be an effective choice, but at the lat time I was working with it, "dnx watch" was broken in docker files with Glenn C's last comment being something to the effect of "i'll fix this after the dust around dotnet-cli settles" (again, totally fair, I discovered the bug during RC1 and overlapping with the dotnet-cli announcement)

HOWEVER back to the "use docker inheritance" thing. Absolutely a preference with many valid options available to you.

In the one I'm proposing your "company level" shared docker file would be (roughly, this is from memory scratch so a bit more of a gist than runnable code)

filename shared_company_image

    from microsoft/aspnet
    RUN dotnet new my_temp && dotnet restore && rm my_temp

then every internal project would run

    from shared_company_image
    COPY . /app
    WORKDIR /app
    RUN ["dnu", "restore"]

You'll see that in this scenario you're actually running DNU restore twice, but because they've already been downloaded ONCE in the above image, the second image only downloads MISSING and UPDATED deps and you save massive amounts of time for every developer at setup & startup.

It's almost like doing CSS bundling and minification.

There's an added bonus for internal IT teams (I guess) that in the shared image you could also "slurp in" other tools or patches that your team feels are critical.

Anyways, I agree that it's preference based, but this one adds a bit of weight in terms of saving frontline developer hours.

In my own dev-flow "docker run" happens pretty often, so if there's a way I'm missing to cut the number of those down, I'd be interested in hearing it.

edit: I should mention I'm working under an agency scenario with dozens of websites and hundreds of developers - we try and make ourselves extremely portable from one project to the next. I've currently got around 15 that I'm actively managing and I may have to parcel out just a couple hours work at a time for a developer.

Oh man.

It's not like I liked the idea of project.json, because it clearly has problems, like being rigid / not extensible.

But I was hoping for a migration towards something like Maven / Gradle / SBT / Leiningen. And extending MSBuild is not a solution towards that.

And it's really not about MSBuild being XML. No, this is about MSBuild being too freaking manual, in an Ant/Makefile fashion. Maven is declarative, it depends on established conventions with overridable settings and has plugins. And it takes care of everything, from dependency management, building, deployment, testing, continuous integration, metrics, etc, things for which people normally use Visual Studio or TFS or other third-party and usually incomplete, bloated and expensive solutions. And sure, providing command line tools that modify MSBuild is nice. But you know, the fact that you need a tool to modify MSBuild highlights a big problem. And no, it's not because of the XML.

With RC2 on Linux (in Docker). In the myget link I just posted, you can see that those EF-npsql packages depend on 1.0.0-rc2-final packages.

Most of the documentation/tutorials you find will be perfectly relevant, but they may be Windows-centric based on .NET's history.

At a really basic level, you simply declare a "static extern" method with a "DllImport" attribute attached to it. For example, you could call "printf" from libc like so:

  [DllImport("libc")]
  public static extern void printf(string message);

  static void Main()
  {
      printf("Hello World");
  }