5 ms·

What a disaster. The tail wagged the dog in the .NET Core team. Every step of the way it became clearer that this was a pet project of some ivory-tower programm

What a disaster. The tail wagged the dog in the .NET Core team. Every step of the way it became clearer that this was a pet project of some ivory-tower programmers and that we would be left to patch together this mess. Try adding a .NET Core project on your build server. You'll hate yourself by the time you get it building.

mking1024 10y ago
Really? We haven't had any problems with our .NET Core projects (a few web apps running on core and a bunch of libraries targeting core). In addition, ASP.NET Core (on .NET core) has been a great stack so far (using it since beta5); I feel very productive with it as well as enjoying the development experience. Why do people need to get fired for this? It doesn't seem like it will be hard to move from project.json back to (a new and improved) csproj.
- mattmanser 10y ago
  Everyone's been having problems with them, how can you have had none? They seem to massively change something every 10 minutes. I also don't get the 'massively productive' comment, in essence very little has changed since, hell even MVC 3, apart from the obsession with DI and a load of packages now don't work. If you weren't 'massively productive' before, you were probably doing something wrong. They just moved a couple of things around and now insist you use npm/bower/whatever hotness they latch onto next week instead of nuget. I'm sure we'll have another blog post about them ditching support for anything but yarn next week. And how long before they change their minds about how controllers work again, it's been like 4 times in the last 5 years now. First MVC controllers, then Web API, then Web API 2, then OData, then .Net Core, all very similar but slightly different with slightly different ways to register them at startup and slightly different things available on the context. Apart from the utter madness that is OData, great for data tables, bloody awful for everything else. It's getting almost as bad as javascript churn but it's one company so it doesn't make any sense.
  - UK-AL 10y ago
    It's was an alpha/beta/prerelease product, you should expect change.
    - DSteinmann 10y ago
      It's not just change. It's difficult to make it work for a single version. It was difficult back when the build tools were a handful of powershell scripts. It was difficult when they moved to the dotnet tooling. Microsoft shouldn't push out an RTM product and call the broken bits "Preview" to absolve themselves of the responsibility to deliver a reliable product. I was evangelical about .NET Core. I stuck with it for years. I stuck with it when Damian admitted that he "doesn't build web apps". I stuck with it during the Release Candidates. It's only when they pushed this out the door and called it RTM that the penny dropped and I accepted the project had been mismanaged.
      - nightski 10y ago
        They announced all of this before .NET Core went RTM. Not only that, the tooling was never made RTM (still in preview). If you jumped on the bandwagon that early then you had all of this information and knew what was coming.
      - manigandham 10y ago
        You should just wait until both the framework and tooling are RTM if that's the stability you need - the framework is already great but if you need the tooling then wait until it's ready. Why complain if you understood the status and assumed the risk?
        mattmanser 10y ago
        Microsoft have always had extremely stable RCs. If you knew anything of the traditional release history for Microsoft you wouldn't have commented. All your post demonstrates is total ignorance of the context or history. It was previously totally fine to use RCs for the last decade, probably way before that too, but I only have experience from then. RC in MS speak meant "pretty much finished, API won't change unless we find something desperately wrong". Then it suddenly means basically pre-alpha, "anything can change, massively, between RC versions".
- DSteinmann 10y ago
  Yes, Really, and I am sure there are some people who have had no problems. That doesn't invalidate the countless hours I spent making this dreadful system work. Did you put it on your build server without installing Visual Studio on it?
  - colemickens 10y ago
    >Did you put it on your build server without installing Visual Studio on it? Huh? `docker run microsoft/dotnet`. Took about 2 seconds to get it running on my Jenkins build server. In reality, it took literally no effort. My entire full stack app requires `make` and `docker` to build and nothing else. The backend is an AspNetCore API.
  - dsp1234 10y ago
    Our build server (TeamCity) does not have VS installed. I can actually tell you the exact software installed on the build server: 1.) Window Server 2016 (Base OS) 2.) SQL Server 2016 Express with LocalDB only (used for longer integration tests that need to validate migrations) 3.) DotNetCore.1.0.1-SDK.1.0.0.Preview2-003133-x64.exe (.NET core SDK 1.0.1 download from https://www.microsoft.com/net/download) 4.) BuildTools_Full.exe ("Microsoft Build Tools 2015 Update 3" https://www.visualstudio.com/downloads/#d-build-tools). If you have this, then you don't need the full VS install 5.) NodeJs (for running webpack as part of 'dotnet publish') 6.) TeamCity and Octopus Deploy agents That's it.
romanovcode 10y ago
> Try adding a .NET Core project on your build server. I've done it in multiple projects, only problems I've encountered were nuget restoring which was easily fixable.
- nkassis 10y ago
  Same nuget been a huge pain in this. I would have been nice to have a ready made msbuild script that would result in web deploy packages (we release with on premise TFS RM) but we were able to make one manually. I expect .net core to have better integration with TFS soon (if not already in the next release)
cm2187 10y ago
That's one thing I don't understand with .net core. You deploy the whole .net framework along your code which then becomes static. And this is targeted at web applications primarily. What about security vulnerabilities? Unless the developers redeploy the application we will be left with an unpatched .net stack and unpatched web server? How is that a good idea? In an ideal world there would be an active dev team busy redeploying and patching every day behind each website. But people who think we live in this world haven't really followed the pretty much constant stream of news about major breaches because of unpatched versions of software being used everywhere. Or am I missing something?
- barake 10y ago
  Bundling the runtime/core framework isn't required. .NET Core applications can be deployed as portable or standalone. Portable: runtime must be installed on target machine Standalone: runtime bundled with application Portable is how non-Core .NET apps have always been, and I believe all the templates in the Visual Studio preview tooling are setup as portable apps. The docs have a good explanation of the differences, and how to configure a project to support either deployment strategy: https://docs.microsoft.com/en-us/dotnet/articles/core/deploying/ https://docs.microsoft.com/en-us/dotnet/articles/core/deploy...
- deleted 10y ago
  [deleted]
- nightski 10y ago
  Probably not a good idea to update the framework without the application knowing. This could cause bugs and unspecified behavior. It's best to test your application against new versions and then deploy a new version of the app.
  - cm2187 10y ago
    The .net framework is pretty much always 100% backward compatible. Again not a problem if you will have an active team maintaining the code. But can you even count how many dead applications and websites you have encountered in your career? At least if the OS gets updated, the application benefits from security patches.

mking1024 10y ago

Really? We haven't had any problems with our .NET Core projects (a few web apps running on core and a bunch of libraries targeting core). In addition, ASP.NET Core (on .NET core) has been a great stack so far (using it since beta5); I feel very productive with it as well as enjoying the development experience. Why do people need to get fired for this? It doesn't seem like it will be hard to move from project.json back to (a new and improved) csproj.

mattmanser 10y ago
Everyone's been having problems with them, how can you have had none? They seem to massively change something every 10 minutes. I also don't get the 'massively productive' comment, in essence very little has changed since, hell even MVC 3, apart from the obsession with DI and a load of packages now don't work. If you weren't 'massively productive' before, you were probably doing something wrong. They just moved a couple of things around and now insist you use npm/bower/whatever hotness they latch onto next week instead of nuget. I'm sure we'll have another blog post about them ditching support for anything but yarn next week. And how long before they change their minds about how controllers work again, it's been like 4 times in the last 5 years now. First MVC controllers, then Web API, then Web API 2, then OData, then .Net Core, all very similar but slightly different with slightly different ways to register them at startup and slightly different things available on the context. Apart from the utter madness that is OData, great for data tables, bloody awful for everything else. It's getting almost as bad as javascript churn but it's one company so it doesn't make any sense.
- UK-AL 10y ago
  It's was an alpha/beta/prerelease product, you should expect change.
  - DSteinmann 10y ago
    It's not just change. It's difficult to make it work for a single version. It was difficult back when the build tools were a handful of powershell scripts. It was difficult when they moved to the dotnet tooling. Microsoft shouldn't push out an RTM product and call the broken bits "Preview" to absolve themselves of the responsibility to deliver a reliable product. I was evangelical about .NET Core. I stuck with it for years. I stuck with it when Damian admitted that he "doesn't build web apps". I stuck with it during the Release Candidates. It's only when they pushed this out the door and called it RTM that the penny dropped and I accepted the project had been mismanaged.
    - nightski 10y ago
      They announced all of this before .NET Core went RTM. Not only that, the tooling was never made RTM (still in preview). If you jumped on the bandwagon that early then you had all of this information and knew what was coming.
    - manigandham 10y ago
      You should just wait until both the framework and tooling are RTM if that's the stability you need - the framework is already great but if you need the tooling then wait until it's ready. Why complain if you understood the status and assumed the risk?
      - mattmanser 10y ago
        Microsoft have always had extremely stable RCs. If you knew anything of the traditional release history for Microsoft you wouldn't have commented. All your post demonstrates is total ignorance of the context or history. It was previously totally fine to use RCs for the last decade, probably way before that too, but I only have experience from then. RC in MS speak meant "pretty much finished, API won't change unless we find something desperately wrong". Then it suddenly means basically pre-alpha, "anything can change, massively, between RC versions".
DSteinmann 10y ago
Yes, Really, and I am sure there are some people who have had no problems. That doesn't invalidate the countless hours I spent making this dreadful system work. Did you put it on your build server without installing Visual Studio on it?
- colemickens 10y ago
  >Did you put it on your build server without installing Visual Studio on it? Huh? `docker run microsoft/dotnet`. Took about 2 seconds to get it running on my Jenkins build server. In reality, it took literally no effort. My entire full stack app requires `make` and `docker` to build and nothing else. The backend is an AspNetCore API.
- dsp1234 10y ago
  Our build server (TeamCity) does not have VS installed. I can actually tell you the exact software installed on the build server: 1.) Window Server 2016 (Base OS) 2.) SQL Server 2016 Express with LocalDB only (used for longer integration tests that need to validate migrations) 3.) DotNetCore.1.0.1-SDK.1.0.0.Preview2-003133-x64.exe (.NET core SDK 1.0.1 download from https://www.microsoft.com/net/download) 4.) BuildTools_Full.exe ("Microsoft Build Tools 2015 Update 3" https://www.visualstudio.com/downloads/#d-build-tools). If you have this, then you don't need the full VS install 5.) NodeJs (for running webpack as part of 'dotnet publish') 6.) TeamCity and Octopus Deploy agents That's it.

romanovcode 10y ago

> Try adding a .NET Core project on your build server. I've done it in multiple projects, only problems I've encountered were nuget restoring which was easily fixable.

nkassis 10y ago
Same nuget been a huge pain in this. I would have been nice to have a ready made msbuild script that would result in web deploy packages (we release with on premise TFS RM) but we were able to make one manually. I expect .net core to have better integration with TFS soon (if not already in the next release)

cm2187 10y ago

That's one thing I don't understand with .net core. You deploy the whole .net framework along your code which then becomes static. And this is targeted at web applications primarily. What about security vulnerabilities? Unless the developers redeploy the application we will be left with an unpatched .net stack and unpatched web server? How is that a good idea? In an ideal world there would be an active dev team busy redeploying and patching every day behind each website. But people who think we live in this world haven't really followed the pretty much constant stream of news about major breaches because of unpatched versions of software being used everywhere. Or am I missing something?

barake 10y ago
Bundling the runtime/core framework isn't required. .NET Core applications can be deployed as portable or standalone. Portable: runtime must be installed on target machine Standalone: runtime bundled with application Portable is how non-Core .NET apps have always been, and I believe all the templates in the Visual Studio preview tooling are setup as portable apps. The docs have a good explanation of the differences, and how to configure a project to support either deployment strategy: https://docs.microsoft.com/en-us/dotnet/articles/core/deploying/ https://docs.microsoft.com/en-us/dotnet/articles/core/deploy...
deleted 10y ago
[deleted]
nightski 10y ago
Probably not a good idea to update the framework without the application knowing. This could cause bugs and unspecified behavior. It's best to test your application against new versions and then deploy a new version of the app.
- cm2187 10y ago
  The .net framework is pretty much always 100% backward compatible. Again not a problem if you will have an active team maintaining the code. But can you even count how many dead applications and websites you have encountered in your career? At least if the OS gets updated, the application benefits from security patches.