221–230 of 317 posts
.Net core is fantastic. What a surprise to find a software from Microsoft that worked a LOT smoother on Linux than on Windows* :D * VSCode/Linux vs VSCode/Windows. Full VS on Windows worked OK.
Earlier quoted context omitted.
It would seem to me that you wouldn't be able to mock all the classes if you followed this strategy.
Well do you really need to mock everything? And if so, how is that different than any other stack? Most of the time this is just "enterprise patterns" without any thought about whether it's worth it. I've seen too many small LOB apps that have 5 tiers of code for no reason.
We have the base MVC project that references services for DI. We load in another DLL via Ninject to add customization on top of those services (custom parsing of some magnetic card swipes for different institutions we deploy to and such). I discovered that while all of our services (~20) had an interface, only one of them was being customized/overridden. This mean that in order to do something as simple as a parameter change, it had to be changed in way too many places: the definition, the implementation, and the usages.
Why have that extra layer? If we need to override in the future, we can add more interfaces. For now, I just want to maintain my sanity.
Earlier quoted context omitted.
Are you making interfaces for everything? Just register and use the class with constructor injection. All those layers of indirection just waste time. What would change with functions outside of classes? You already have anonymous functions/lambdas, static classes and extension methods if it's about instantiation overhead, and local (nested) functions. Can you explain a scenario where this doesn't work for you? For n…
It would seem to me that you wouldn't be able to mock all the classes if you followed this strategy.
Earlier quoted context omitted.
Well, you expect http library to be as good as everywhere else.. like python requests. When library is not updated due to app compatibility issues i would not call it modern. It is good enough for basic use, tho.
HttpClient supports http2, the latest protocol features, has been rewritten in managed code with sockets, and includes advanced handling to balance connection lifetimes with DNS updates. It's about as modern as it gets and we run 10 billion requests per day through this code without issue. How does a lack of support for an RFC (which is still being revised) that outlines where a cookie should not be accepted in edge…
A.) Not even stdlib
and
B.) Doesn't support async/await
Is an odd choice.
Earlier quoted context omitted.
> Windows userland is being rewritten in COM since Vista I am not sure "rewritten" is the proper word as this implies replacement, but in reality nothing gets replaced (at least as far as the user/developer facing stuff go) and the new stuff are added on top (or alongside, depends) the existing stuff. Also i'm not sure if the whole "exposing new stuff in COM" thing is a good idea overall. The classic Win32 GUI APIs m…
COM is kind of like GObject and something like it has a place. COM usage is fairly limited because using it easily requires compiler support, which only very recently was included in the Community editions of Visual Studio. You can also access COM via language bindings; most .NET code you write is COM-enabled, for example, and is accessed from non-CLR code as COM. MinGW has stuff that lets you use and generate COM cl…
Ext-VOS design document clearly refers to Java and J++.
Secondly, I have been developing for Windows since Windows 3.0 and wonder which compiler support features do you mean. Even the old express editions had the required Windows SDK tooling for COM.
sadly .net core still lacks a good pdf library that is not priced over the top. (and at least supports building pdfs and creating pdf/a 3's.)
https://www.reportlab.com/dev/opensource/
This is a Python implemented API/framework. However, you could use IronPython (compiles to CLR and .NET) and import Reportlab. I've never used it that way, but it's worth the try!
Hope this helps.
And yet it's not used for rockstar projects (change my mind).
What's a "rockstar project"? :-)
Earlier quoted context omitted.
It's still nowhere near the same level of experience that Rider or VS offer.
Thank goodness that VSCode is a different experience! VS and Rider are a pain in the ass to setup and maintain and VSCode provides the essential UX better than just about anything else at this time. I can have VSCode installed and running with my personal settings on any OS within 2 minutes flat. I don't have to find a secret license key, login with any account, or pick through a list of 100 features in the installer…
Earlier quoted context omitted.
Nah, that key problem will eventually be sorted out with a couple of generational changes.
I'm serious (even if it may not sound like it). COM is a fantastic platform, because it provides simple and efficient interoperability between language runtimes. But code written for tracing GCs cannot be automatically transformed into COM's (or any) reference counting scheme. And that's why we have this endless tug of war between those who want to build on top of COM versus those who want to build on top of .NET. It…
It works even on Linux https://github.com/Const-me/ComLightInterop I also have these parts, especially about the interop. Libraries like drm, kms, gles, udev, and many other kernel APIs are only usable from C or C++.
Had very few issues with IUnknown-based interop. On Linux, my interop library retains .NET objects with GCHandle while they are referenced by C++ code. On Windows, it’s done automatically by the runtime. C++ implemented objects are automatically retained on both OSes.
What exactly do you think is a hard problem about such interop? Leaks due to ref.count cycles are possible, but I’m not sure it’s such a huge deal. There’re many good reasons to keep interop API surface small, with obvious “who owns what” relations.