We Keep Coding

gRPC client having lots of issues and not working

I started using gRPC with Visual Studio 2022 and never saw so many issues as now.
When I wanted to create an additional Proto file I got the error saying that I need to specify the language. That's weird, because I selected the proper option which is designed for C#. So it never worked and I simply had to copy default greeter file.
I created the console app which uses this default greeter service and it even worked. But I added the additional proto and created another fairy simple service and it did not want to compile it referring to some missing types of something. I can't remember the exact error message but I resolved it only by reducing the grpc.* package version to 2.27.I found this answer by googling and I find it weird that Microsoft releases something what does not work in the most simple case scenario.
I decided to test my new test grpc service and created the client:
var channel = GrpcChannel.ForAddress("https://localhost:5001");
var client = new Greeter.GreeterClient(channel);
var reply = await client.MySimpleMethodAsync(new MyRequest { Id = 123 });
Console.WriteLine(reply.Message);
Console.ReadKey();
The MySimpleMethodAsync method is very simple, it just reads the record from the DB using Dapper, nothing special.
Surprisingly there was no compilation error, but when I tried to run it (along with the server app) I got the exception on the line var reply = await client.MySimpleMethodAsync, saying Grpc.Core.RpcException: 'Status(StatusCode=Unimplemented, Detail="Service is unimplemented.")'
I don't understand why it says so. The service is implemented, it's compilable! Googling did not help but I found that other people are having the same issue too.
Eventually I found that if I modify the grpc service and for some reason it does not like it and then I rollback the changes, it's not compilable anymore! I clearn solution, rebuild it - nothing helps! The only thing which helps is addting the brand new project and copy pasting the previous "stable" code.
I've never seen such the ...technology that never works!
Anyway, now the most important issue for me is #3 , why it says the service is not implemented?

Could not start Windows Service, Error 1064

I wrote a Windows Service to run on Win10, and it worked perfectly fine until I decided to change it a bit. I rewrote some logic, tested it in both Debug and Release configurations, and everything was fine. Then I uninstalled the current version of the service using installutil.exe /u %servicename.exe% and reinstalled it again using installutil.exe %servicename.exe%.
For some reason, this new version cannot start, and it crashes with Error 1064. This is the full error text:
Windows could not start %servicename% service on Local Computer. Error 1064: An exception occurred in the service when handling the control request.
The last time I installed this service, I ran into some difficulties, but quickly fixed them by changing the Log On properties. This time, it is not working. Please help with this issue.
Thanks.
Update 1
Here are my Main() and OnStart() service methods:
Main()
static void Main()
{
#if DEBUG
var service = new SalesforceToJiraService();
service.OnDebug();
Thread.Sleep(Timeout.Infinite);
#else
ServiceBase[] ServicesToRun;
ServicesToRun = new ServiceBase[]
{
new SalesforceToJiraService()
};
ServiceBase.Run(ServicesToRun);
#endif
}
OnStart()
protected override void OnStart(string[] args)
{
this.ConfigureServices();
this.timer.Start();
this.logger.Information("SalesforceToJira service started.");
}
Update 2
More code:
ConfigureServices()
protected void ConfigureServices()
{
this.configuration = ConfigurationHelper.LoadConfiguration(ConfigurationPath);
this.logger = ConfigurationHelper.ConfigureLogger(this.configuration.Logs.LogsPath);
this.timer = ConfigurationHelper.ConfigureTimer(this.configuration.ProcessInterval.TotalMilliseconds,
(sender, eventArgs) => this.ProcessCasesAsync(sender, eventArgs).GetAwaiter().GetResult());
this.salesforceClient = new SalesforceCliClient(this.configuration.Salesforce.CliPath);
this.jiraClient = Jira.CreateRestClient(
this.configuration.Jira.Url,
this.configuration.Jira.Username,
this.configuration.Jira.Password);
}
I'm using Newtonsoft.JSON for deserializing a JSON configuration file, Serilog for logging, System.Timers.Timer for periodic events, AtlassianSDK for the Jira API and some wrappers over Salesforce CLI for Salesforce.

Thanks to #Siderite Zackwehdex's comment, I was able to find the full stack trace of the underlying exception in EventViewer, under:
Windows Logs\Application
In my case, my service is named "HttpDispatcher", which appears in the "Source" column in the top pane.
I could see immediately it was due to a dependency issue where my .NET 4.7.2 project was not pulling across my .NET Standard references. (That ol' chestnut).

I faced the same issue. The reason was I forgot to set the Database connection properly in configurations.

I had this exact same error 1064 starting my service. For me the user I had the service registered as was not a valid user in the database. Once added, it worked great.

I also had the same error in my Windows Service.
The reason was it can't read a configuration parameter, so it crash.
Adding some validation (bugfixing), the Windows Services can start it correctly.

In my case the error was due to issues with Event log name
It got fixed after I went to RegEdit and deleted old service name from HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

I have also faced this issue. In my case it is due to connection fail with the data base. I think it is due to code throw the exception.
My error :
Windows could not start the service1 service on local computer.
Error 1064: An exception occured in the service when handling the control request
I corrected my issue by updating the third party DLL.

I faced the same issue, here is how I resolved it after troubleshooting.
If you are running service on the Server with multiple users, make
sure to run the service as admin user. Click on the service
properties and then on Log on tab click on this account and provide
the admin user name and password.
And If your service is accessing some shared drive, then make sure
you have a general user on all servers for accessing the shared
drives and add the user as local admin as well.

For me it happened when I tried to restart a process. Turned out the process was hanging in 'Stopping' so I had to kill it manually via command line and the PID.

Trouble with Quit() on VisualFoxPro Application within C#

I've created a WebAPI webservice that accepts requests from a legacy Visual FoxPro system. The service needs to parse the request and then launch the VFP runtime in order to execute some legacy FoxPro code to actually "process" the request.
I have some code like this:
try{
foxApp = new VisualFoxpro.FoxApplication();
foxApp.DoCmd(#"do hqinit with .T.");
...
foxApp.DoCmd("close all");
foxApp.DoCmd("release all");
foxApp.Quit();
}
catch{
...
}
The foxApp.Quit() constantly throws and error and the FoxPro Application is still left running (I can see it in the Task Manager).
Based on this SO post, I tried the following:
try{
foxApp = new VisualFoxpro.FoxApplication();
...
while(System.Runtime.InteropServices.Marshal.ReleaseComObject(foxApp) > 0) {}
However, while I no longer get the error I was getting when trying to foxApp.Quit(), VFP Application is still left running after each call to the web service.
How do I ensure that VFP gets closed down at the end of each web request?
Update
I just tested again and realized that the first code block does NOT throw an error. Rather, it simply hangs the server. However, if I add foxApp.DoCmd("clear all") before foxApp.Quit() I get an error stating that:
Cannot clear the object OPANEBROWSER because it is in use.
None of my code references an OPANEBROWSER object some I'm not sure where that is coming from.

Got it!
I had installed VFP9.0 SP2 on the server and technically, I'm launching the app itself. On my dev environments, I always disable the Task Manager pane that MS pops up by default. However, I had not done that on the server VFP environment.
Once I disabled the Task Manager in VFP environment so that it did not get displayed on Start of VFP, everything was golden.

Service Fabric Debugging with CodePackageDebugParameters

When a new service fabric application is created inside VS the default template adds debugging magic to the scripts so that an application running inside service fabric can be debugged. The powershell scripts passes the _WFDebugParams_ as application parameters to the cluster. I can't figure out to get it working in code. The code I'm currently using is
var debugParameters = new CodePackageDebugParameters(
"MyApplicationPkg",
"Code", null, null,
"Main",
#"C:\Program Files\Microsoft Visual Studio 15.0\Common7\IDE\Remote Debugger\x64\VsDebugLaunchNotify.exe",
"{625F9A8A-16A1-42E6-948F-D5D9AF04F1AB} -p[ProcessId] - tid [ThreadId]",
null, null, null, null, null, null, null);
nameValueCollection["_WFDebugParams_"] = CodePackageDebugParameters.GetDebugParameters(new[] { debugParameters });
await app.CreateApplicationAsync(new ApplicationDescription(ApplicationName, ApplicationTypeName, ApplicationTypeVersion.ToString(), nameValueCollection)).ConfigureAwait(false);
I have only VS2017 installed on my machine with the remote debugger tools. My questions are the following:
What path should be used for the VsDebugLaunchNotify?
How is the GUID
determined (I currently paste in a random GUID as debug parameters)?
Another problem that I have is that CodePackageDebugParameters is basically unusable. I had to copy paste the whole class definition into my project because the ctor and all the properties are internal.

In summary, the GUID is a correlation id of a named pipe set up by Visual Studio Debugger. It is later used by Service Fabric Cluster to ping VS back with process id and thread id that it should auto-attach to.
Here is the more detailed explanation of what is happening when you hit F5 in Visual Studio (Please note that this is a result of investigation done on my local dev environment and might not be 100% accurate as parts of this is not covered by documentation for VS or SF):
Service Fabric Extension scans solution that is about to be debugged and lists all SF services to be deployed into local cluster
For each service it runs StartListener method using undocumented debugger interface IVsDebugLaunchNotifyListenerFactory110. So if there are x services in the project there will be x notifiers started
This in turn creates a named pipe called MicrosoftVisualStudioProcessLaunchNotify_{<<GUID>>} where the GUID part is generated for every function call
Service Fabric Extension deploys SF application passing the GUID in _WFDebugParams_ as indicated in the question.
During service startup, SF uses the _WFDebugParams_ to run VsDebugLaunchNotify.exe passing the GUID, ProcessID of service that was started and ThreadID debugger should auto-attach to.
NOTE: It looks that StartListener can only be used from inside the Visual Studio Extension.

Service Fabric Tools uses this WFDebugParams parameter, so when service fabric application that is being debugged can attach to VS debugger. It is not meant to be used by end user.

WCF C# webservice returns nothing, ends client unexpectedly

I have several web services residing on a LIVE server that return data to a client. For some reason since I have moved the services from TEST server to the LIVE server the services are breaking.
My logs indicate that the services are executing correctly serverside but on the client side 'nothing' is returned. I.e. the client exists unexpectedly and the local variables defined 'do not exist in the correct context' when debugging.
PDFLive.PDFServiceClient client = new PDFLive.PDFServiceClient();
string[] response = client2.ReceiptPDF("document string");
string foo = "othercodetobeexecuted";
If I debug over this code, it will attempt to execute 'string[] response ...' and then just skip over the other code and end the client without returning any errors or exceptions and making the local variables
string[] response
and
string foo
'Non existent in the current context'
I have enabled Diagnostics in my web.config and they indicate no errors. Again on the serverside the code executes correctly its the return data that isnt reaching the client or reaching the client but not being processed correctly on the client side.
Ive tried creating the default WCF project and deploying it on my LIVE server and consuming it externally alas, same issue. Could it be something on the Server that is disallowing data to be sent?
I have searched high and low but without any meaningful error being returned its difficult to know what the issue could be. Has anyone had any experience with this issue or come across it in anyway?
I can consume the service via an external test client but when adding a service reference to a C# project it displays the behaviour mentioned above.
SOLVED:
I had to uncheck 'optimize' code in the project settings and my debugger works perfectly now. I got the idea from this post A curious case of Visual Studio 2010 debugger

SOLVED: I had to uncheck 'optimize' code in the project settings and my debugger works perfectly now. I got the idea from this post A curious case of Visual Studio 2010 debugger