|
I can't help you with the print class, but I do have an idea about the testing.
Do you have MS Office installed on your development machine? If so, I believe that also installs a "Print to PDF" printer driver. You could use that to print to a PDF file instead of the printer.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I didn't think of that! I have CutePDF that I print all my orders with, before I email them.
Thanks!
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
On top of that, ChatGPT should not be used to write code. It sucks at writing anything beyond "Hello World" and WILL lead you down incorrect paths.
|
|
|
|
|
I'm beginning to realize that now.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
I'd like to put all of my custom classes into a .NET Framework DLL so that I can share them among many different executables.
If I install a NuGet package to the DLL, are the classes in that package supposed to be available to any EXE that holds a reference to the DLL?
Or NuGet packages can't be shared that way, meaning the package must be installed to the EXE, not the shared library?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
In my experience, NuGet packages are on a project basis (dll; exe), though you can manage them at the solution and project level.
You can "share" a dll's Nuget package via the dll as an "interface"; otherwise, I know of no way to surface "name spaces" from a dll other than the one it "owns".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Thanks for the response, Gerry. Can you elaborate on what you mean by sharing the package as an interface? Do you mean I'd have to write code (interfaces) that specifically expose the types in the NuGet package?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Yes. A proxy.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
When you use or deploy the .DLL to another .EXE project, you have to ship the .DLL's in the NuGet package with your .DLL. Your .DLL won't work without them.
As for being available to the .EXE, yes, the NuGet .DLL's will also be available to the executable project, just like they were for your .DLL project.
|
|
|
|
|
OK, thanks Dave.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
The classes and functionality from the NuGet package won't be automatically available to the executables (EXE files) that reference this DLL. Each executable project that uses the DLL must also have its own references to the required NuGet packages.
|
|
|
|
|
I have a small game executable (not my game) that, when I close it down, opens my default browser with the game's maker's web site. Presumably it is just opening an http and Windows 11 handles it from there. Is there a way to prevent this from happening? —either to enclose the app's environment from the outside or to create an isolated environment that then executes the game (or some other way)? It would seem a little weird to me if I couldn't prevent that from happening to a specific Windows process. Windows provides a vast array of services to apps, but in terms of security, it might make sense to be able to prohibit certain operations for a process at the OS level. Does Windows provide any control for this?
|
|
|
|
|
Does Windows provide any control for this? No, not directly. I don't know of any O/S that does.
If the app is just shelling out to a URL, you really cannot stop an app from doing that. The shell will take commands from anything and there's nothing you can do to stop it.
Firewall rules will not help because the URL is being launched by the shell and the browser is the registered handler for HTTP/HTTPS. Your game isn't involved in handling the URL itself so there's no process-based firewall rule that will prevent the launch of it.
Writing up a rule to prevent access to the URL or IP will still bring up a browser window, but with a failure message.
|
|
|
|
|
|
I know the way I stopped it from happening with the game that I had.
I paid for the game, rather than just continuing to use the free demo.
|
|
|
|
|
Are there any .onnx Modules that are included already or plans to have them included?
The only ones I'm interested in are a .pt file format and the YOLOv5 6.2 doesn't work very well at all. (Probably because I don't have a GPU)
|
|
|
|
|
What does your question have to do with this forum? If you're asking about something you saw in an article, you should ask in the article itself.
|
|
|
|
|
It's related to the YOLOv5 .NET model.
|
|
|
|
|
|
Thank you, I'll post it there instead.
|
|
|
|
|
Hello guys,
I have an issue related to dependency injection in the Program.cs of a .Net 7 application.
In this case it's an API, but that does not really matter.
Before calling the line:
var app = builder.Build();
I am adding a few singletons normally with :
builder.Services.AddSingleton<IMyConfig, MyConfig>();
builder.Services.AddSingleton<IMyHttpClient, MyHttpClient>();
My issue is that the HTTP client singleton requires info from the config singleton, and it's not a simple case of injecting the former into the latter.
We can't use appsettings.json to manage our configuration, that would be too easy, and because the second one is an HTTP client, I have this code :
builder.Services.AddSingleton<IMyHttpClient, MyHttpClient>();
builder.Services.AddHttpClient<IMyHttpClient, MyHttpClient>(client =>
{
client.BaseAddress = new Uri(myConfig.myURI);
client.DefaultRequestHeaders.Accept.Clear();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
}).ConfigurePrimaryHttpMessageHandler(() =>
{
return new HttpClientHandler()
{
UseDefaultCredentials = true
};
});
.. all this still before I call builder.Build();
I have already googled and chatGPT'd the problem, but the solutions I get are for .Net 6 at best, and do not apply.
My current solution is to use builder.Services.BuildServiceProvider().GetService<imyconfig>() to get an instance of myConfig, but then the builder is called twice, so this instance is lost, and after the builder.Build(), I have to read my config again.
Technically, this works, but it's ugly and triggers my OCD.
If there's any DI god out there, what am I missing ? 
Thanks in advance
Fred
modified 28-Apr-23 9:43am.
|
|
|
|
|
If you're "stuck" with a given framework, count yourself lucky if you get something to work. When it does, move on instead of thinking about "ugly"; it's a waste of time.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
If you want a singleton then you have to inject it into a thread flow that does not depend on requests but rather something like the start up method.
But as with the other reply, the point it to deliver something. And you need to have a realistic view about what might actually need to be easily replaced in the future. So does it actually need to be injected. Configuration might be it but you can do that with a standard factory idiom also.
|
|
|
|
|
|
Ok, a few months late admittedly. I'm not a fan of all this functional style boostrapping in ASP.NET core. I find the whole thing obfuscated and difficult to work with and often grapple just to do something simple like config or logging.
Anyway, I have this in my code:
services.AddHttpClient<IMyClient, MyClient>((serviceProvider, httpClient) =>
{
var opts = serviceProvider.GetRequiredService<IOptions<MyHttpOptions>>();
httpClient.BaseAddress = opts.Value.BaseUrl;
})
So, if you just want to get access to config, I think you can just retrieve it from the service provider given as the second parameter to the lambda, no BuildServiceProvider() required.
Regards,
Rob Philpott.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
