|
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.
|
|
|
|
|
I'm in the process of building a HTML server using vb.net which dose the job quite well. Currently I'm trying to add a function for downloading files. The sending of plain text works without a glitch (see code 1). However sending files such as executables (*.exe) or Excel (*.xls) files dosen't work (see code 2).
The file once downloaded simply wont run. Upon closer examination (by opening the downloaded file in Notepad) signs of incorrect encoding are typically seen. there are a lot of question mark characters and when compared 1 on 1 with the original file it is clear that the encoding is the problem. Simply said I have no idea on how to resolve this and internet research isn't proving to be a reliable bron of information. Since the problem is one of encoding what I have tried is to read the exe file through a file stream-read and convert its context (probably binary) to text and send that with result that there there is an inprovment but the problem still persists and ultimatlhy the file still dosen't work.
How do I resolve this?
CODE 1
With My404HtmlPage
.Append("HTTP/1.1 200 OK" & Environment.NewLine)
.Append("Content-Type: text/plain & Environment.NewLine)
.Append("Content-Disposition: attachment; filename=" & Chr(34) & "Download.exe" & Chr(34) & Environment.NewLine)
.Append(Environment.NewLine)
.Append("Hello World!")
End With
CODE 2
With My404HtmlPage
.Append("HTTP/1.1 200 OK" & Environment.NewLine)
.Append("Content-Type: application/octet-stream & Environment.NewLine)
.Append("Content-Disposition: attachment; filename=" & Chr(34) & "Download.exe" & Chr(34) & Environment.NewLine)
.Append(Environment.NewLine)
Dim bytes = My.Computer.FileSystem.ReadAllBytes("C:\Original.exe")
Dim MyString As String = Encoding.UTF8.GetString(bytes)
.Append("content-bytes:" & MyString)
End With
|
|
|
|
|
Umm... There is NO encoding for any binary file.
Encoding means "interpet the bytes as this", which will change how the bytes are interpreted, changing them when read. You absolutely do NOT want to change a single byte. You should be just sending the bytes, not creating a string out of them.
|
|
|
|
|
Dim MyString As String = Encoding.UTF8.GetString(bytes)
You just destroyed the content of the file.
Any file that is non-text based is pure binary and should only be read and written as such.
|
|
|
|
|
Bart van Tuijl wrote: Dim MyString As String = Encoding.UTF8.GetString(bytes)
No, apply them bytes?
That's what Dave says and he is right. Bytes are that.
No encoding. Write them bytes directly.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
