4 ms·

$ docker run -it microsoft/dotnet:latest # dotnet new # dotnet restore # dotnet run You can run asp.net apps from this container too as they have p

$ docker run -it microsoft/dotnet:latest # dotnet new # dotnet restore # dotnet run You can run asp.net apps from this container too as they have packaged libuv into a nuget package.

tychuz 10y ago
zsh: command not found: dotnet Does not work on OS X following these instructions: https://www.microsoft.com/net/core#macosx https://www.microsoft.com/net/core#macosx
- colemickens 10y ago
  I greatly prefer using docker for reasons like this. Otherwise, I'm not sure what's going on. I just ran through those instructions on my Mac. After installing that package and starting a new shell, `dotnet` was working. There's a slack room which might be able to provider further support: http://tattoocoder.com/aspnet-slack-sign-up http://tattoocoder.com/aspnet-slack-sign-up
  - tychuz 10y ago
    Dunno, restarted my Mac - still not working. Running latest version - 10.11.5
    - colemickens 10y ago
      (I and more authoritative individuals can help more in Slack without cluttering up this thread too much.) If the Installer did its job, you should have /usr/local/share/dotnet on your $PATH and it should contain a `dotnet` binary among some other items.
- runfaster2000 10y ago
  We're working on this issue. See open issues: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/known-issues.md#users-of-zsh-z-shell-dont-get-dotnet-on-the-path-after-install https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/k...
alexc05 10y ago
protip: make your own docker image that inherits from one where dotnet restore has been 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. https://github.com/aspnet/Home/issues/1312 https://github.com/aspnet/Home/issues/1312 https://github.com/OmniSharp/generator-aspnet/issues/527 https://github.com/OmniSharp/generator-aspnet/issues/527 old-speed for every deploy & first deploy under new method: ~3m30s new-speed - second & subsequent deploys if dependencies are unchanged: ~9s I've tried to get it into the right place from a few different angles, but at the end of the day (after some discussions with the MS team) I think they want to leave this quality-of-life improvement out in favor of making sure the base-template is "pure" (actually a perfectly acceptable choice IMO, different priority for the tool provider vs. the front-line-dev) 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.
- colemickens 10y ago
  (personal opinions/preferences here:) I wouldn't really recommend rebuilding your container from scratch as a way of doing normal daily development. Why not just mount your source into the container as a volume and do rebuilds from there? You can even mount in the nuget cache so that it persists between development sessions. 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.
  - alexc05 10y ago
    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.

$ docker run -it microsoft/dotnet:latest # dotnet new # dotnet restore # dotnet run You can run asp.net apps from this container too as they have packaged libuv into a nuget package.

tychuz 10y ago

zsh: command not found: dotnet Does not work on OS X following these instructions: https://www.microsoft.com/net/core#macosx https://www.microsoft.com/net/core#macosx

colemickens 10y ago
I greatly prefer using docker for reasons like this. Otherwise, I'm not sure what's going on. I just ran through those instructions on my Mac. After installing that package and starting a new shell, `dotnet` was working. There's a slack room which might be able to provider further support: http://tattoocoder.com/aspnet-slack-sign-up http://tattoocoder.com/aspnet-slack-sign-up
- tychuz 10y ago
  Dunno, restarted my Mac - still not working. Running latest version - 10.11.5
  - colemickens 10y ago
    (I and more authoritative individuals can help more in Slack without cluttering up this thread too much.) If the Installer did its job, you should have /usr/local/share/dotnet on your $PATH and it should contain a `dotnet` binary among some other items.
runfaster2000 10y ago
We're working on this issue. See open issues: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/known-issues.md#users-of-zsh-z-shell-dont-get-dotnet-on-the-path-after-install https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/k...

alexc05 10y ago

protip: make your own docker image that inherits from one where dotnet restore has been 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. https://github.com/aspnet/Home/issues/1312 https://github.com/aspnet/Home/issues/1312 https://github.com/OmniSharp/generator-aspnet/issues/527 https://github.com/OmniSharp/generator-aspnet/issues/527 old-speed for every deploy & first deploy under new method: ~3m30s new-speed - second & subsequent deploys if dependencies are unchanged: ~9s I've tried to get it into the right place from a few different angles, but at the end of the day (after some discussions with the MS team) I think they want to leave this quality-of-life improvement out in favor of making sure the base-template is "pure" (actually a perfectly acceptable choice IMO, different priority for the tool provider vs. the front-line-dev) 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.

colemickens 10y ago
(personal opinions/preferences here:) I wouldn't really recommend rebuilding your container from scratch as a way of doing normal daily development. Why not just mount your source into the container as a volume and do rebuilds from there? You can even mount in the nuget cache so that it persists between development sessions. 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.
- alexc05 10y ago
  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.