|
Hello OriginalGriff,
Thank you for taking the time to reply.
Best regards,
MC
|
|
|
|
|
For something completely different. You could try to create a shortcut or batch file to run an Autohotkey script to change the setting then start the game.
GOG games should be easy, and you might be able to run the steam games from the desktop shortcut steam can create.
Just a thought.
Ron
Jack of all trades, master of none, though often times better than master of one.
|
|
|
|
|
I have an internal nuget. It pulls in the nuget for NSB 7.5.
The dependency info clearly shows it is pulling in 7.5.
However, when I then pull my internal nuget into a project, it attempts to put NSB 8.0 as the transient NSB dependency for the internal nuget.
I do not at all understand why this is happening or how to fix it. Has NSB messed up their nugets? What am I missing? Help. Please.
|
|
|
|
|
Why have you posted this in the C# forum? It clearly has nothing to do with writing C# code.
|
|
|
|
|
Well, you're very right. But also, very wrong.
|
|
|
|
|
Well that does not explain anything. If you want people to help you then you need to give proper details of your problem. And I still cannot see anything relevant to C# in your question.
|
|
|
|
|
Nevermind, I'll ask stack overflow. They're nicer about these things.
Seriously, this is the first thing I think I've ever asked here. Maybe .NET would be better, but I think if there are people who would have this answer they more likely to poke here.
|
|
|
|
|
jochance wrote: Seriously, this is the first thing I think I've ever asked here. Well after the other 300 odd messages you should know what the process is.
|
|
|
|
|
Sorry, I do not care about or for your pedantry. I simply do not.
|
|
|
|
|
|
Is there a better forum to ask questions about VS projects?
I can seem some overlap with others (like Managed C++) but nothing that seems to be specific about VS Projects.
|
|
|
|
|
It could go in .NET Core but... It's just the case here is going to more likely get the right eyes.
It doesn't really matter now. Fixed. (another nsb nuget was the cause, it required higher, so it was forcing it to pull a higher version - that nsb nuget was only in the top-level, so wasn't seeing that happen pulling this same thing into others).
My biggest beef is just the absolute ham-fisted pedantry. But it isn't like I ask or answer questions much here nor is it exactly inspiring to do so in the future. Maybe that's the point? Imaginary internet point hoarding?
Maybe it's just been a long day. Will never much care for that kind of stuff though.
|
|
|
|
|
|
I don't see anything in the question relevant to VS either. And I did ask OP to clarify his problem, but seems he wasn't interested.
|
|
|
|
|
Richard MacCutchan wrote: relevant to VS either
From the post
"when I then pull my internal nuget into a project,"
I figured that mean using a project via VS.
One can manage them outside of VS but I doubt many people do. Certainly I would presume that most do it in VS so that is how I read it.
|
|
|
|
|
It seems that the .NET 8 infrastructure code that interacts with the service control manager provides a layer of abstraction over the Start and Stop commands.
Therefore I don't see how to directly issue a service stop command. The service is passed a CancellationToken object, but I've been informed that you can't cancel such a token without access to the CancellationTokenSource.
When the service runs, all I have is the token, not the source.
So how do I shutdown and exit the service from code running inside the service?
SOLUTION:
Below is the template code produced by Visual Studio when you create a .NET 8 Windows service:
I simply created a property on the service class itself that can be set from inside the service and indicates to the outside world whether the service wants to shut down.
I called it StopFlag .
public sealed class WindowsBackgroundService(
MyWindowsService myWindowsService,
ILogger<WindowsBackgroundService> logger) : BackgroundService
{
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
try
{
myWindowsService.OnStart(new string[0]);
while (!stoppingToken.IsCancellationRequested && !myWindowsService.StopFlag)
{
await Task.Delay(TimeSpan.FromSeconds(1), stoppingToken);
}
}
catch (OperationCanceledException)
{
}
catch (Exception ex)
{
logger.LogError(ex, "{Message}", ex.Message);
Environment.Exit(1);
}
}
}
The difficult we do right away...
...the impossible takes slightly longer.
modified 11-Feb-24 15:36pm.
|
|
|
|
|
|
Griff, thanks for the reply.
The method and object you mention are only in the .NET Framework.
I recently upgraded the service to .NET 8, which uses a different paradigm.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Store a "semaphore" (or "command code") somewhere and have the service look at it every so often. Use pull instead of push, and let it shut itself down.
"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
|
|
|
|
|
Richard Andrew x64 wrote: logger.LogError(ex, "{Message}", ex.Message);
Just noting that from the support position I have found it useful to log both when it started and when it stopped, regardless of why it stopped.
|
|
|
|
|
I have some simple code that worked when it was running on the .NET Framework 4.8, but after converting the project to .NET 8.0, the code is unable to open a subkey under HKLM because of an "UnauthorizedAccess Exception".
try
{
using (RegistryKey BaseKey =
RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64))
{
using (RegistryKey SubKey =
BaseKey.CreateSubKey("Software\\CompanyName\\ProductName"))
{
DatabasePath = SubKey.GetValue("DBPath") as string;
SubKey.Close();
BaseKey.Close();
return Result.Success();
}
}
}
FACTS:
The registry key already exists when this code runs.
The code is running under the LocalSystem account as a Windows Service.
The initial open of the base key, HKLM apparently succeeds, but the BaseKey.Handle member is null immediately after the call to OpenBaseKey and before CreateSubKey.
Please ask for more details.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Got any anti-virus running? I've seen Trend get in the way like this before, though that was quite a bit ago.
|
|
|
|
|
To be honest, you shouldn't really be using the Registry at all - access to it is going to get more restrictive rather than less as OS's advance.
There are other ways to store info, particularly paths to DB that don't require the registry - here is the one I use: Instance Storage - A Simple Way to Share Configuration Data among Applications[^]
I created it because I have multiple apps which need access to the same DB server and when I changed PC name I had to update loads of different apps. Now, they all use the same data on each machine and it's a single change on each PC to get the connection string. It may be a little overkill for you situation, but It's made my life a load easier!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
When the keys are little sandboxes only pertaining to your application, why wouldn't you want that centralized there and why wouldn't they make it work more like that?
I don't really disagree and could see it going as you say... ditch the registry. I just don't get why IF the context is little sandboxed subsections of the registry instead of "you can edit anything or you can edit nothing".
|
|
|
|
|
That was the original idea: a single centralized depository for all config info. So it grew and grew, and bloated massively, slowed down everything and became a source of problems because there was no defined (or enforceable) separation of App A info from App B, much less system related info. It also added a route by which trojans could inject themselves into other apps very simply by modifying the config info.
So it became depreciated as a centralized store for new apps because of the problems it caused, and security features evolved as UAC was introduced which deliberately made it harder to use. Those continue to become more restrictive as the OS evolves - at some point it will probably become off limits to all non-admin apps (it's only not at present for backward compatibility with legacy applications).
If it had been designed as a sandbox environment in the first place, it could have been a really useful secure store - but it never was and that lack of foresight shows in the zombie version we currently have!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
modified 14-Feb-24 3:02am.
|
|
|
|