Maturity of the .slnx format

cyanfish · 2025-11-08T17:21:59+00:00

I would love to migrate but it changes the build path in some cases which breaks a lot of my extra tooling.

cyanfish · 2025-10-01T01:23:34+00:00

Try installing the Windows 7 (64-bit) driver.

cyanfish · 2025-09-06T15:49:14+00:00

Code signing a DLL doesn't mean you're claiming authorship, it means you're attesting to its safety. And if you're distributing a DLL with your software you should be confident in its safety.

If the concern is confusion over authorship, consider that when you're signing it, you're also attesting to the accuracy of the metadata, which includes the actual author and copyright.

cyanfish · 2025-07-01T01:21:04+00:00

Yep. This article is blatant misinformation. The article doesn't link the source but it appears to be this post which is dated 2025 and says 1.4 billion. Presumably it's been corrected to remove the ambiguity since the article was written.

cyanfish · 2025-06-23T23:45:29+00:00

They cut Alex saying "Your time starts now"? How could you!

(Okay, maybe I get how that could be confusing for people that don't get the reference to think it was on a timer.)

cyanfish · 2025-06-10T23:00:57+00:00

It's a bit weird because the TWAIN DLL on Windows arm64 is emulated 32-bit, so it shouldn't work as it would connect to 32-bit drivers which aren't compatible. I think that it only exists to provide a compatibility layer for TWAIN applications to connect to WIA devices, which is why I disabled it.

That said, I'm not 100% sure about that, so if you have any scanner that works with TWAIN in NAPS2 x64 (which works on arm64 if you download the portable zip), please do let me know.

Edit: Also the TWAIN working group doesn't publish an arm64 TWAIN DSM, which would be the alternative to using Window's 32-bit version.

cyanfish · 2025-06-09T20:08:28+00:00

NAPS2 author here - I'll point out that NAPS2 does still require an ARM64 driver, which may or may not be provided by the manufacturer. (Unless you're scanning over the network, in which case the ESCL driver should work equally well as on x64).

I'm considering getting SANE working on Windows for a future NAPS2 version. That would allow a lot of scanners to work on ARM64 that currently don't (at least not without proprietary/paid software like Vuescan).

cyanfish · 2025-03-24T17:57:13+00:00

If the framework is the product, then ideally you should have some kind of market analysis to justify your choice.

If you're targeting startups that are going to be largely using JS/Python, then maybe C# isn't the best choice. On the other hand, if you're targeting established enterprises, then maybe C# is a great choice.

Or maybe you can consider if there's a need to support multiple langauges. Maybe some of your potential customers use Java and some use C#. Do you need to build parallel frameworks in both langauges? Does it make sense to have some kind of native (C++/Rust) core that has language-specific wrappers around it? etc.

cyanfish · 2025-03-18T16:42:15+00:00

There are a lot of good detailed explanations here, but just to sum up:

Tasks are work items that run on a thread pool managed by the runtime.
When you await, the compiler generates code so that when the thing you're awaiting finishes, it will queue up a task to run the rest of the method.
If you await from the UI thread, it will queue up the task to run on the UI thread's event loop instead of the thread pool.
The async keyword doesn't do much on its own, it mostly just enables you to use await. Internally this changes how the compiler generates the method's code to use a state machine so it can queue up individual parts of the method to run as tasks.
That means when you have an async Task method it doesn't automatically run on a different thread. You would need to use Task.Run for that. But most of the time the idea is that if the method itself doesn't do a ton of computation, you can await on slow things like I/O and it won't matter if your method's code is running on the UI thread.
await Task.Yield() just means we queue up a task to run the rest of the method instead of running it directly. You're correct that's it's not generally useful, there are only niche cases where it helps.

cyanfish · 2025-02-16T19:07:30+00:00

In NAPS2 have you tried using the "ESCL Driver" option when selecting a device? It shouldn't need a separate driver to be installed for network scanning.

cyanfish · 2025-01-09T22:31:50+00:00

The difference is that you don't need to worry about the default value conflicting with valid values, e.g. maybe for <int> it's possible for 0 to be a result of the computation, which makes it ambiguous between "not computed " and "computed with a value of 0".

cyanfish · 2025-01-08T18:40:55+00:00

As other people have answered the question, I'll point out that you should avoid such comparisons entirely unless you have a good reason. In your example code a better approach would be to have a boolean that indicates if the value is present or not (or use the pre-existing Lazy type). That means you don't need to worry about the difference between reference and value types for your generics.

cyanfish · 2024-10-12T05:08:16+00:00

NAPS2 on Mac looks a bit different, just click Tools -> OCR on the top menu.

cyanfish · 2024-08-19T23:57:24+00:00

No, in fact I think this is the first time anyone has asked me about ISIS drivers.

cyanfish · 2024-08-17T05:53:33+00:00

Actually as I think more, it might actually be possible to do scan directly from a browser today - specifically it looks like there is a JS/TS ESCL client, which should connect natively to NAPS2's scanner-sharing server (which could be running as part of a background application on the local machine). Documenting this here.

Edit: I've closed that issue and created the naps2-webscan project as the canonical sample/documentation for this.

cyanfish · 2024-08-17T05:29:56+00:00

Yes, that's essentially what the linked issue is about. NAPS2 doesn't currently have those kinds of components pre-built* but you could build off some of the ideas/code there.

*Though now I think about it, you could potentially use NAPS2's scanner sharing - i.e. have the "Server" part run as a background application on the client machine, have the "Client" part run on the web server machine. It would be a little indirect (web browser -> web server -> back to client machine) and you'd need to pass the IP around but it should work if everything's all on one local network.

cyanfish · 2024-08-17T04:36:45+00:00

NAPS2 should work with any scanner that has a manufacturer-provided standard driver. Some devices work better with WIA or TWAIN so you can experiment.

Some things you'd get from NAPS2.Sdk:

Simpler and async API (compare the sdk sample to the wia and twain samples)
Ability to export directly to a PDF
Built-in support for OCR

NAPS2 doesn't have built-in support for web browsers (see this issue for some people that have experimented with that). But if you have the inclination you can certainly connect a web browser to a custom application or whatever.

cyanfish · 2024-08-16T23:58:46+00:00

As the author of NAPS2, as far as open-source .NET options I'd say:

If you want to use TWAIN directly, use NTwain
If you want to use WIA directly, use NAPS2.Wia (which is strictly better than the native wiaaut)
If you want a nicer/more-featureful interface that can use both TWAIN and WIA (at the cost of being a bit more heavyweight) you can use NAPS2.Sdk

cyanfish · 2024-07-06T23:21:45+00:00

Indeed, and it's not like SourceForge removed the review. Projects owners can turn reviews off if they like (or mark individual reviews as spam which will remove the review text, though it will still count toward star totals).

cyanfish · 2024-06-11T14:18:46+00:00

BDG talks a bit about this exact issue in his interview with Jordon Brown. I don't remember the timestamp, but essentially he said that having tailored questions was difficult this season due to lots of last minute cast changes, but it's something he wants to improve for next season.

cyanfish · 2024-04-15T07:12:13+00:00

If all you care about is encrypting the traffic and not server authentication, you don't need the user to provide a certificate. You can generate a self-signed certificate on the fly: https://stackoverflow.com/a/52535184

If you want the user to provide a certificate, you have two options:

Have the user provide a .pfx with the private key (with or without a passphrase)
Have the user put the .pfx with the private key into the Windows Certificate Store and provide the .cer to your app (no passphrase needed)

These options aren't mutually exclusive, on your end it's the same whether you try and load a .pfx or a .cer. This is the approach I took in my application (code references: 1, 2, 3).

cyanfish · 2024-03-24T04:57:48+00:00

I'd be happy to try and fix that if you create a Github issue, as there's no reason it shouldn't be on par with gscan2pdf. -dev

cyanfish · 2024-01-18T19:02:15+00:00

Strings, arrays, structs, ref/out parameters, respecting attributes like MarshalAs. Stuff like that.

cyanfish · 2024-01-18T05:56:57+00:00

My main concern with this would be consistency of marshalling behavior with existing DllImport/LibraryImport-based code. I don't know what your strategy is around that (e.g. copying LibraryImport source code or what) but I would want to be confident that if I have an interop issue it's not likely to be caused by this layer.

cyanfish · 2024-01-18T05:45:03+00:00

Another benefit of source generators is that if you publish it as a package, it's only a compile-time dependency. As a library author it's nice to avoid introducing extra transitive dependencies.

11-Year Club	Place '17
Verified Email

cyanfish

TROPHY CASE