I never understood why they didn't port IQueryable. I never really updated my Azure functions from runtime v1 to v2 becuause of that. Dealing with Table Storage without it is a pain in the ass.
.NET Core 3.0 Concludes the .NET Framework API Porting Project
171–180 of 317 posts
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#172Earlier quoted context omitted.
JetBrains stuff does feel sluggish and occasionally hangs on my 2016 XPS-13 with 8G of ram. It gets the job done, but it's not pleasant. On my new Ryzen 3600 with 32G of ram it runs smooth. So if you go for JetBrains, I definitely advise not to cheap out on the hardware. Rider on Linux was very good for me, working on C# azure functions.
32G?!? Where does one find such employers??? Not to mention how crazy it sounds having 32GB for an IDE. Visual Studio, Netbeans and Eclipse run perfectly fine with 8 GB.
These days 32G is starting to become more of a necessity as apps take more and more RAM. And if you're a gaming, 8G doesn't cut it anymore for some games;
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#173Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio. One might think the verbosity can be reduced by clever coding (and adopting a functional style), but that's not so…
I don't believe you will ever get functions outside of classes in C#. It is antithetical to the entire ethos of the environment.
Thank god we won't. Functions outside classes never did make sense to me. People love to hate classes sometimes. For me, everything starts at classes and structs;
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#174And yet it's not used for rockstar projects (change my mind).
It will be. Just a matter of time. As things stabilize; Unity Engine will certainly use it moving on. They could already be using it. Not certain;
It just doesn't make sense starting a new project with old .NET Framework from now on;
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#175Earlier quoted context omitted.
Hey for people that don’t follow windows internals and politics closely, what did the devTools champion ? What are the longhorn ideas that are getting into windows ?
Long story short, that you kind have to assemble from blog posts, forum comments, between the lines articles and so on. Longhorn was to be built on top of .NET and there were lots of issues, regarding performance, stability and what not. Apparently it was more a thing of WinDev (owner of Windows and C++) and DevTools (owner of VS and .NET) each pulling to their side instead of collaborating. As proven later by Singul…
I think Sinofsky was still in Office when this was happening. He comes into the picture with Windows 8 since Microsoft wanted Windows to be as successful as Office had become. Jim Allchin (https://en.wikipedia.org/wiki/Jim_Allchin) was in charge at the time of Vista.
Office had stuck with regular the regular Windows platform and were focusing on UI and getting into a regular release rhythm under Sinofsky. People forget but Office releases used to be a real crapshoot and Microsoft needed to move to a true subscription model at some point (the original activation wasn't it.) To do this you need regular updates at least a few years apart before you can even get close to what's needed for a subscription business. Sinofsky seems to have been a real success here, but not so much in Windows.
Looking back the expectations for Vista could never meet the reality. Windows was fundamentally not ready as a product or team to deliver on any of the promises. This was not much different from Cairo (https://en.wikipedia.org/wiki/Cairo_(operating_system)) as it turned out. If the focus had been on the fundamentals like regular releases they may have been achieved some of what is promised with the right compromises. I also wouldn't discount some of the hardware changes in the period. We were getting multi-core and there was a transition to 64-bit.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#176.NET Core 3.0 was major achievement for Microsoft and I like the air surrounding the project and some around it like Visual Studio Code and Windows Subsystem for Linux. The teams working for Windows development are overall on a roll these days and it's both sad and a little mysterious how Windows 10 is still struggling with QA issues, decisions like dismantling their internal testing teams, dual control panels and in…
This oldie seems relevant: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c...
1 year to build Windows Vista's new shutdown menu, with a total of 43 people somehow involved in its design. If this is how Windows developers still have to work, it's no wonder.
That said, I would readily believe that the roots of this story have more to do with the complexity of modern OSes than any particulars of Microsoft culture. In terms of software quality, OS X peaked about 15 years ago, and has been steadily getting flakier ever since. And the Linux community has been struggling for virtually its entire existence, without success, to deliver a well-polished desktop experience.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#177Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio. One might think the verbosity can be reduced by clever coding (and adopting a functional style), but that's not so…
can't you just put static functions inside of a static class and use them with "using static StaticClassName"?
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#178Earlier quoted context omitted.
>It means I know where the switches are, and more importantly, what they do Or even more importantly than that, that they even exist in there somewhere.
My goodness. Recently I went to play a game on my laptop, something i don't normally do. I'm not even normally a windows user. It has this 'feature' where if a key is pressed then it disables all mouse clicks for X number of seconds. This is to prevent a forearm from tap to clicking on the touchpad while typing. Absolutely makes sense. Only... I had a mouse plugged in. It disabled a physical USB mouse from clicking a…
I've got a Macbook Pro and it doesn't seem to have or need this feature in the first place.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#179Question: I haven’t tried building a windows app in 10 years. That said, in the past I found it darn easy to wire an interface up quickly. I recently downloaded visual studio and could not quickly figure out how to get a GUI going (design view would not show). What is the recommended approach with this new stuff? Some buttons and textboxes on a form with an onChange method and a data bound grid? This used to be prett…
If you were trying WinForms, the designer does not yet work for .NET Core apps. The WPF designer is supposed to work with .NET Core, but there was a bug in it in the first VS release that might have been the cause of your issue[0]. I also had problems doing anything other than toy WPF projects. IMO the .NET Core support for the GUI frameworks is not ready for prime time. Building GUI apps in .NET Framework is still a…
Very helpful. I thought WPF / Core was the recommended / modern approach.
I just fired up an attempt using Windows Forms / Net Framework after scrolling down to that combo. It looks good so far.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#180Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio. One might think the verbosity can be reduced by clever coding (and adopting a functional style), but that's not so…
The closest you'll get to free floating functions are methods in a static class. The static classes essentially become namespaces. Then with static using directives, you don't need to spell out the namespaces. https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... You can even put every global function into a single class but still organize your code across multiple files by making them all part of the same…
I have found that large partial classes declared across many physical source files creates lots of issues with intellisense throughput. At 50+ partials, you are looking at solid 10+ second delays in the IDE between when you typed something naughty and when you are informed of it. This behavior has been replicated across many different computers and versions of visual studio, so I think it's just a fundamental limitation.
We have some solid use cases for free floating functions (e.g. business rules that need to be able to arbitrarily invoke each other) which we ultimately decided to scope to one public function per class. This allowed for some other interesting advantages in terms of consolidating tightly-coupled business logic that was formerly spread across the codebase (e.g. items used only by the one function - mappers, request/response models, private utility methods, etc). We even explicitly duplicated out some logic in order to enable completely isolated verticals of BL.