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.)
I've extensively used itext with no issues on core
.NET Core 3.0 Concludes the .NET Framework API Porting Project
141–150 of 317 posts
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#142Earlier quoted context omitted.
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…
May be I don't understand something, but how does it differ from e.g. operating file handles? For example in Java you're supposed to use try-finally to close file handle. You should do the same with reference-counted objects, just manage their lifetime manually. And finalizers will close it for you if you forgot to do that (that should be considered as a bug, but not very serious).
It doesn't differ from that, but in languages that assume the presence of a tracing GC, that pattern is only used for resources other than memory.
And therefore you can't (as far as I know anyway) compile arbitrary C#/Java/JavaScript libraries down to reference counted COM in order to make those libraries available to C++ or Rust code.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#143Given 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 find structural typing is mostly necessary when someone messed up and used a class where an interface should have been used.
I'm now currently in the position of having to decide whether it's better to accept defeat or use T4 or similar to write the 1000+ line wrapper class to undo the mistake... You'd think Microsoft would at least remember to do dependency inversion through interfaces in their own C# code.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#144Earlier quoted context omitted.
May be I don't understand something, but how does it differ from e.g. operating file handles? For example in Java you're supposed to use try-finally to close file handle. You should do the same with reference-counted objects, just manage their lifetime manually. And finalizers will close it for you if you forgot to do that (that should be considered as a bug, but not very serious).
It doesn't differ from that, but in languages that assume the presence of a tracing GC, that pattern is only used for resources other than memory. And therefore you can't (as far as I know anyway) compile arbitrary C#/Java/JavaScript libraries down to reference counted COM in order to make those libraries available to C++ or Rust code.
You can also use that pattern for memory management in .NET.
For example stack allocations and unmanaged memory handles.
.NET COM interop take care of exposing .NET classes to other COM aware languages.
https://docs.microsoft.com/en-us/dotnet/standard/native-inte...
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#145Earlier quoted context omitted.
I love it every time I get the 'old' control panel. It means I know where the switches are, and more importantly, what they do. The new UIs change with every minor update. Layout, labels and semantics. It's truly horrible. Please don't encourage Microsoft to mess it up even more.
>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 after a keypress. Even after disabling the touchpad entirely it continued this behaviour.
After some Googling there should have been a switch in the modern Windows 10 style mouse config. But it wasn't there.
More Googling, "go edit this registry key" but i didn't have that registry key.
More Googling, the registry key depends on your touchpad driver.
More Googling finally found a way to disable it globally with regedit.
#1 Why was the switch not available in the mouse settings #2 Why was it applied to a usb mouse #3 Why did the registry key differ depending on mousepad driver.
Just a nightmare.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#146sadly .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.)
I'm currently building an open source (not copyleft) PDF library for.NET standard [0] and I'd be interested to hear more what you need on the document generation side.
The current generation API for my library is extremely limited because I've never needed one but you are the perfect market research participant. It's an API I'm actively looking to improve.
PDF/A compliance is probably quite a way off though.
[0]: https://github.com/UglyToad/PdfPig [1]: https://github.com/UglyToad/PdfPig#document-creation
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#147sadly .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.)
I've extensively used itext with no issues on core
itext is extremly overpriced. btw. you can't use the AGPL version in any closed source project.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#148Earlier quoted context omitted.
What's the problem asking experienced developer to learn F#? That is course assuming they do not refuse the work?
Team dynamics in large companies can be quite challenging. In addition, whoever made that decision might become responsible for project delays, inability to hire, people writing bad code, destroying work-life balance etc. And not just you, everyone up the chain will get blamed for choosing a programming language with a near-zero market share. Generally large companies and enterprises are resistant to change, and my a…
Your original point was about inability to recruit developers. That is why I asked. From my experience it was never a problem for seasoned developer to get a grip on new language barring few very exotic cases. I completely understand other factors in enterprise.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#149sadly .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.)
I'm currently building an open source (not copyleft) PDF library for.NET standard [0] and I'd be interested to hear more what you need on the document generation side. The current generation API for my library is extremely limited because I've never needed one but you are the perfect market research participant. It's an API I'm actively looking to improve. PDF/A compliance is probably quite a way off though. [0]: htt…
wow that looks really nice.
actually we mostly do html to pdf, but maybe I can look into your project and try to add it (if there is a nice html/dom library like java has with jsoup).
basically we don't need a lot, mostly switch fonts/text sizes/images (generated barcodes, logos) and of course pdf/a-3(a/b/u) for invoice. so apis that translate the html into the layouting of pdf is the bigger problem.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#150Earlier quoted context omitted.
If you install the VS Code's C# extension, you should be getting autocomplete and quick fixes such as adding impport statements automatically. https://code.visualstudio.com/docs/languages/csharp
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. Then, once it's installed, well VSCode is just a better experience for the basic act of editing source code. Multiple cursors, quickly opening files by typing the name (without having to type a greater than sign followed by a space first every time like you do in VS), sane default keyboard shortcuts for managing/splitting documents and so on... Plus, it's got way better facilities for working with front-end web code than VS ever had and some other major features such as remote editing oh and one other little thing: it's fully cross-platform.
And that's the reason for VSCodes wild success. Let's hope Microsoft never fucks it up by trying to glom the rest of their Azure/Microsoft Account crap onto it too much.
Luckily, I don't have to work on anything that needs a designer anymore, like WinForms, but if I did I would certainly install VS. Even then - I think I'd only use VS for the designer and go back to VSCode for everything else. (And I love Windows and I used to love VS, having used both of them for 30 years and 15 years respectively.)
But the VSCode team also covered a lot of ground faster than VS ever did, adding feature after feature. So, what do you want for C#? I'm certain that we'll be getting it soon.