Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Core 3.0

devblogs.microsoft.com

Post reply on HN
Print view View original

171–180 of 183 posts

Re: .NET Core 3.0

#171

Post by avgDev »

mieseratte wrote: post #161
keithnz wrote: post #154

Earlier quoted context omitted.

its very simple to get .net core DI working, shouldn't be much code other than registering your types / service. await new HostBuilder().ConfigureServices((context, services) => { // services.AddTransient.... }).UseConsoleLifetime().Build.RunAsync()

I’m talking DI for ASP.NET MVC 5, non-Core. That required a custom provider (trivial), and non-obviously a custom ControllerFactory as I picked Core DI instead of a more fully-fledged solution. Unfortunately there is very little obviousness in documentation and germs often get conflated and confused. Perhaps this is MS trying to get me to take one of their infamous certification courses?

That is because MVC 5 did not support DI out of the box. This has been fixed with Core. It is quite easy now, since I was able to figure it out haha.

Re: .NET Core 3.0

#172

Post by Kihashi »

strangecasts wrote: post #99
rajeev-k wrote: post #79

Earlier quoted context omitted.

Docker is a better way to distribute apps than Electron, in my opinion. From a developer point of view you just build a regular web app, so better than Electron. From the user's point of view, Docker is better because of isolation, and because there is nothing to install. You run just one command to download and run the image. If you want the app to have its own window then use Chrome's "Create shortcut" command. Thi…

For the end user there is something to install - specifically, Docker, which is quite... hefty on Windows

I've had to debug every install of docker for windows that I've done because it doesn't set something up correctly. Usually this involves googling the error message, finding a github thread where people are talking about which builds this affects, and then trying one of three or more powershell commands to fix whichever part of the install failed. In the most recent attempt, the error message told me to enabled virtualization in the BIOS, but it was actually that HyperV had not been enabled properly[1]. It was installed and the UI ran, but if you tried to start any VM, it would fail. I doubt debugging this sort of thing is feasible for an end user.

[1]: https://stackoverflow.com/questions/39684974/docker-for-wind...

Re: .NET Core 3.0

#173

Post by jen20 »

atonse wrote: post #5
privateSFacct wrote: post #2

What's crazy is that this is what C# should have always been. I was into Mono way back because I thought niavely it was going to be more successful, but I think if C# had gone this route earlier -> the whole python / go etc popularity boom might have been softer and MS would have had a first class player that would have increase # of folks easily able to build in windows. That and I never got to develop successfully…

I’ve thought about this but I doubt it. The big change has been the perception shift. .NET was always really solid tech. Microsoft has always had stellar developer technology. But the love affair with open source and the super villain role that Microsoft played, is what kept people away, not the tech itself. I remember wanting to give a talk about how amazing C# was to a ruby group. I never did it, but it was definit…

We have been selling a relatively complex product built using C# for many years now. It is perhaps unusual in that it was built on Linux for Mono primarily, and then ported to .NET on Windows subsequently.

What we have seen over the years is:

1. Deploying on Windows became less popular, partly because it was much harder to manage at scale than Linux, and partly because of the price of licensing.

2. Mono was seen as a toy, and is often considered a critical risk by purchasers. This was even true after Microsoft bought Xamarin, and thus de-facto control of the project, and despite the fact that it was far easier to patch bugs in the open source runtime than in the closed-source .NET Framework (and we ran into several in each).

C# (and even more so F#) is a great language, but was hamstrung early on by Microsoft's approach to competition - I think had this been different early on, the world would look very different with respect to popularity for critical infrastructure vs the JVM. Whether it's late enough to salvage something for a large number of non-traditional-MS is debatable - it will be interesting to see how it plays out over the next few years.

Re: .NET Core 3.0

#174

Post by jen20 »

james_s_tayler wrote: post #169
FlorianRappl wrote: post #108

Earlier quoted context omitted.

That's not the root of the problem. Personally, I wish MSBuild would be more powerful and would allow mixed compilation where some files are in C#, some in F# (or VB.NET or some other language targeting the CLR). Right now most companies (in the .NET world) just run on C# and no one tries anything new except when it arrives in C# (and even then its a struggle - even though the situation has improved a lot in recent y…

I thought you could actually do that already? I watched a talk about F# on YouTube recently and the guy said they used F# for domain logic and C# for plumbing code and he showed them working together...

The 'normal' approach to this is two different assemblies. There is, however, support in the CLR (I assume it still exists) for assemblies built from different languages - it's just not well exposed by tools.

Re: .NET Core 3.0

#175

Post by jen20 »

ygra wrote: post #134
FlorianRappl wrote: post #108

Earlier quoted context omitted.

That's not the root of the problem. Personally, I wish MSBuild would be more powerful and would allow mixed compilation where some files are in C#, some in F# (or VB.NET or some other language targeting the CLR). Right now most companies (in the .NET world) just run on C# and no one tries anything new except when it arrives in C# (and even then its a struggle - even though the situation has improved a lot in recent y…

This isn't really due to MSBuild, as the C# compiler has that limitation already. MSBuild just calls it. Basically a single assembly has to be written in the same language. You could probably get something similar with multiple assemblies and ILMerge.

> Basically a single assembly has to be written in the same language.

This is actually untrue - though the tooling does not make it easy.

If the output type of a 'project' is set to `module` instead of `assembly`, it can be added as a module reference to another project which builds an assembly.

The downside used to be that completion in the IDE didn't work, but as far as I'm aware there's no real reason why multi-module assemblies couldn't easily be exposed by tooling if it was considered important enough.

Re: .NET Core 3.0

#176

Post by jen20 »

ygra wrote: post #157
FlorianRappl wrote: post #156

Earlier quoted context omitted.

I don't expect the C# compiler to understand F#, but in my opinion there should be language independent ways to create CLR assemblies. MSBuild (which calls the right compiler for each project) could also understand (and did iirc) compiler-independent project types that still produce assemblies, however, from mixed sources. Now the C# compiler would only be called for the C# sources. > Basically a single assembly has…

The C# (and other .NET compilers) treat an assembly as the smallest unit they will emit. You'd have to change that to some semblance of "object files" instead along with a "linker" step afterwards to allow for an assembly to be made up of different languages. Again, this is how the compilers work currently, so MSBuild (well, the default targets) just go along with this. This has nothing to do with MSBuild, which basi…

> The C# (and other .NET compilers) treat an assembly as the smallest unit they will emit.

`module` in your project file (or `/target:module` at the command line, and you get a smaller unit.

Re: .NET Core 3.0

#177

Post by noisem4ker »

charrondev wrote: post #139
strangecasts wrote: post #99

Earlier quoted context omitted.

For the end user there is something to install - specifically, Docker, which is quite... hefty on Windows

If I remember correctly it also requires windows pro or enterprise. These 2 requirements make this fundamentally unusable for most. - Windows 10 64-bit: Pro, Enterprise, or Education (Build 15063 or later). - Hyper-V and Containers Windows features must be enabled.

Docker Toolbox, although less polished, is based on VirtualBox and happily runs without Hyper-V. The only thing I've found missing is the control panel GUI.

https://github.com/docker/toolbox

Re: .NET Core 3.0

#178

Post by merb »

manigandham wrote: post #113
jsingleton wrote: post #98

Earlier quoted context omitted.

It's usually a good idea to wait for the patch release before updating. This applies to most software, including VS, VSC and .NET Core. Being an early adopter sucks unless you're just testing it out. If it's your job then wait for it to stabilise and for the real-world bug fixes. The next Long Term Support version of .NET Core will be 3.1. It should be out in November.

.Net 3.0 has gone through about a dozen preview releases and the last 4 have a go-live production license. It's much better tested than the old .NET Framework with its monolithic releases.

I can at least name two bugs. both bugs do not apply to everybody and one is fixable with some additional code. I reported both in preview9, one should be included into 3.0 but was not. the other will be fixed in 3.1:

- https://github.com/aspnet/AspNetCore/issues/13696 - https://github.com/aspnet/AspNetCore/issues/13715

(Edit: corrected first link)

Re: .NET Core 3.0

#179

Post by ygra »

jen20 wrote: post #176
ygra wrote: post #157

Earlier quoted context omitted.

The C# (and other .NET compilers) treat an assembly as the smallest unit they will emit. You'd have to change that to some semblance of "object files" instead along with a "linker" step afterwards to allow for an assembly to be made up of different languages. Again, this is how the compilers work currently, so MSBuild (well, the default targets) just go along with this. This has nothing to do with MSBuild, which basi…

> The C# (and other .NET compilers) treat an assembly as the smallest unit they will emit. ` module ` in your project file (or `/target:module` at the command line, and you get a smaller unit.

Ah, learned something new today. Thanks.

Re: .NET Core 3.0

#180

Post by james_s_tayler »

jen20 wrote: post #174
james_s_tayler wrote: post #169

Earlier quoted context omitted.

I thought you could actually do that already? I watched a talk about F# on YouTube recently and the guy said they used F# for domain logic and C# for plumbing code and he showed them working together...

The 'normal' approach to this is two different assemblies. There is, however, support in the CLR (I assume it still exists) for assemblies built from different languages - it's just not well exposed by tools.

Ah that must have been it.
Post reply on HN