$ docker run -it microsoft/dotnet:latest
# dotnet new
# dotnet restore
# dotnet run
That way each subsequent run in DEVELOPMENT will happen in seconds as opposed to minutes.
I've been trying to get a PR Shepparded though the MS open source process for months.
old-speed for every deploy & first deploy under new method:
new-speed - second & subsequent deploys if dependencies are unchanged:
ANYWAYS, 9 seconds vs 4 minutes per recompile is a BIG deal. You'll thank yourself and drink way fewer cups of coffee over the course of a day.
I've been playing with docker and dotnet since they gave a demo at Build 2015... if I could figure out a way to quit my job and just do open-source docker tooling, kubernetes, mesos, and dotnetcore I would do it in a heartbeat. I'd love to create the architecture for the "bootstrap" of scalable dotnetcore microservices.
I only do a from-scratch restore and compile whenever I do a "final container" build to actually push/deploy. In that case, I want it doing a full restore, plus it already has some mechanism to capture the publish output from my build container and dump it into a more minimal runtime container.
On the other hand, what you're doing "locks in" your dependencies at a single point in time when you build your intermediate base layer. That may be desired for orthogonal reasons.
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)
RUN dotnet new my_temp && dotnet restore && rm my_temp
COPY . /app
RUN ["dnu", "restore"]
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.
Does not work on OS X following these instructions: https://www.microsoft.com/net/core#macosx
There's a slack room which might be able to provider further support: http://tattoocoder.com/aspnet-slack-sign-up
See open issues: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/k...
Announcing ASP.NET Core RC2
Announcing Updated Web Development Tools for ASP.NET Core RC2
.NET Core RC2 is supported on the following platforms:
Red Hat Enterprise Linux 7.2
Debian 8.2 (8.2, 8.3, 8.4)+
Ubuntu 14.04 (16.04 support is coming at RTM)
OS X 10.11
Windows 7+ / Server 2012 R2+
Windows Nano Server TP5
That's just a horrible idea.
If it was Core.NET I wouldn't know without actually reading the detail, which I am not likely to do because it's a low margin project.
I'm a little disappointed that http://dot.net is just a redirect to this and they're not hosting from that. :)
In the cross-platform section, what is Linus? Do they mean Linux?
I can't stand that each of their primary link leads to a completely different website, each with its own navigation and visual design.
Documentation lags severely behind though.
I understand that supporting 14.04 makes sense for now and that supporting non-LTS releases is maybe an unjustifiable burden, but 16.04 is a LTS release and I tried installing the 14.04 packages and it didn't work as they've got unmet dependencies.
From : "Question: project.json is going away? Sadface
What were the things we liked? It was small, contained NuGet information, and could be edited by hand. Damian does not want to lose any of those benefits, and that is why they are working in several steps to complete this migration. Additionally, the team is building tooling at the command line so that you don’t have to work with the project file directly. Consider a possible npm-like command like “dotnet install json.net –save” to add a NuGet package to your project. There will be first class commands like this available.
The new MSBuild will not have a complete list of every file, so that should reduce the size of the build file. It will still be XML, but the team is committed to making that experience better for all .NET projects. This will be an enhanced MSBuild that has all of the best parts of project.json"
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.
(The proposal would not add the individual file contents of the project into the xproj, however.)
This was an article highlighting the community discussions on this: https://wildermuth.com/2016/05/12/The-Future-of-project-json...
I work on RavenDB, a NoSQL database for .NET. We tried porting our database technology to Linux using Mono, and we encountered many serious bugs.
We have since abandoned that port and moved to .NET Core. It is successful, and we will be releasing that in the next major version of our software, RavenDB 4.0.
There is no GUI support for .net core, there is no plan to support GUI apps AFAIK, it will be mostly ASP.NET. Sure somewhere in the future WPF might be ported, but right now if you want GUI you need to use Mono and GTK+.
.net core is really asp.net core right now. Keep in mind that microsoft doesn't maintain 3rd party DB drivers or ORM adapters for Entity Framework, aside from sqlite maybe. I wasn't able to run PostGres with EF with the RC1 on .net core, while it worked when targeting mono.
Also Mono is full framework compatible; whereas .NET Core doesn't have the same api surface area as full framework (a lot of the Win specific stuff dropped, some older apis dropped etc). So it depends on the feature set you need also.
Or possibly netbsd https://github.com/dotnet/coreclr/pull/4504/files
Those version may require self-build or a bit more heavy lifting.
(I work on the core libraries for .NET)
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:
public static extern void printf(string message);
static void Main()