I'm working with a legacy c# console application that uses WCF and MSMQ. It's several years old and was developed under VS2015 running in Windows 7. It runs fine in that environment.
But, when I simply copy the project to a Windows 10 machine running VS2019 and run the application in the VS2019 debugger I get the following exception when it attempts to queue a WCF/MSMQ message...
An error occurred while opening the queue:The queue does not exist or you do not have sufficient permissions to perform the operation. (-1072824317, 0xc00e0003). The message cannot be sent or received from the queue. Ensure that MSMQ is installed and running. Also ensure that the queue is available to open with the required access mode and authorization.
The queue does exist. In fact the app actually creates it if it's not there - which it did on 1st run.
Under Message Queuing the associated queue has full access granted to my user account.
MSMQ is installed. Again, the app itself created a queue.
I'm running VS2019 (and therefore the application under debug) "as an administrator" - which is another pain...
Again, this runs just fine in the older Windows 7 / VS2015 environment. It's only when the project is copied into the Windows 10 / VS2019 environment. Obviously there's some setting in the new environment...
Any thoughts?
Many thanks!
-- Curt
This may be due to a problem with the base address in the configuration file. The server name needs to be included in the base address. If the server name of win7 and the server name of win10 are different, it may cause this problem. There are similar questions in this blog, you can refer to it.
For more information about "Message Queuing to Windows Communication Foundation", you can refer to this link:
https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/message-queuing-to-wcf
Related
We deploy our .NET applications (.NET-Framework 4.5.2 and upwards) on a network drive. To explain, we build it in Visual Studio and copy the contents of bin/release. Several users who are connected to different terminal servers of Windows Server 2012 R2, Windows Server 2016 or Windows Server 2019 via RDP run the application. Most of the time it works great, but from time to time the application stops working. Either it doesn't start at all or it crashes at a specific action. The action at which it crashes is always different. After we close the application for all users on the terminal server, it works again without any problems. It looks like all users share the same process and if one crashes, it crashes for everyone.
Is this a known problem and do you have any solutions? For easy and fast update reasons, we cannot install the application directly on the server.
Two weeks ago I was able to run and analyse .net projects on windows 10 but after some times, it stopped. I am getting this app can't run on your PC , To find the version for your PC, Check with the software publisher.
I was following this url Scanning using Ms Build
I have also changed my local security option, the option of allow UIAccess applications to prompt for elevation without using the secure desktop to Enabled.
I am using windows 10.0.16299 x64 and there is no recent updates done on the computer.
I am running the command from sonar-scanner-msbuild-4.0.2.892\SonarQube.Scanner.MSBuild.exe and I have sonarqube-7 installed and running.
What Am I missing, I am not sure what caused the execution to stop and I checked there is no antivirus or firewall blocking and there is no error .
My company recently using tivoli workload scheduler (TWS) to remote trigger jobs from an z/OS to window server. we have tested the tivoli can trigger the mssql services successfully.
The problem now is we have a .NET CL program that we used daily to extract some data in AS400 to mssql server, it was worked perfectly before when using windows scheduler and trigger daily in specific time frame. now we trying to centralize the scheduler so the TWS remotely trigger a prepared batch file (it will trigger the CL program).
but the execution of the CL program show following error while trying to connect to AS400 DB.
The .Net Framework Data Providers require Microsoft Data Access Components(MDAC). Please install Microsoft Data Access Components(MDAC) version 2.6 or later.
EDITED:
in normal scenario, we were assumed the program can trigger successfully, it should be just like using windows scheduler, set a schedule and execute it. the only differences is the scheduler is not windows scheduler for now, but switch to TWS and trigger the CL program remotely. but the execute show the above error during executing the CL program. we have no idea why this error comes up.
we tried to rerun the CL program and schedule it in windows scheduler, works fine. but schedule on TWS remotely, error.
For the testing and observation we have done so far:
Our server is Windows server 2008 SP2 x64, I have made some researches the MDAC used in old version windows while server 2008 should deliver with a newer version of MDAC (WDAC 6.0) and it cannot be reinstall so i assume the MDAC/WDAC must be install correctly.
the CL program was compiled with .NET 2.0/ 3.0 / 3.5, and tested all of them produce the same error.
they error logs were able to produce to sql server DB, so I assume the connection driver using in CL program have no problem. but it might be caused by IBMDA400 driver.
TWS use the admin account in our server to trigger the batch files, a TWS client (listener) is installed in our server for trigger programs in our server, but we dont know how they connect to our server (SSH? telnet?) and they seems donot actually login to our server for remote trigger(trigger our job in silent mode).
we are desperate in seeking any solutions, if anyone could provide any clues or thoughts, it would be very helpful and provide a big help to the people with the same problem in the future.
Thank you very much!.
For those searching, I recently got this error in a web app despite MDAC 2.8 SP1 being already installed on the 2008 box. We re-installed MDAC and it did not seem to fix. Stopping and starting the app pool for the affected web app fixed the problem. It's not 100% clear if the re-install was necessary, or if windows updates or something required an iisreset that didn't happen.
The reason for this error is that the application pool is trying to read a registry key from the HKey_Current_User hive which isn't always loaded.
The solution is as follow:
Open IIS management console
Click on "Application Pools"
Right-click the pool for your web site and select "Advanced Settings"
Change the setting "Load User Profile" to True
I can only give you some avenues to investigate.
You may want to try using the IBM DB2 iSeries ADO.NET Data provider instead of using the IBMDA400 OLE DB provider. My team had a similar experience when we went through a re-platforming project to a newer Windows Server that was x64. For some reason we had very strange results trying to use the older OLE DB providers on our .NET Windows Services. We later found out it was due to our server being 64bit.
I am suspecting you are having an issue with the IBMDA400 is a 32bit driver. Check if you are compiling your .NET CL program as 64bit. You could try to compile your program as a 32 bit application and enabling Wow64 on your server.
Hope one of these leads you to a solution!
I am running into an issue when attempting to use MapPoint libraries within our C# .NET application from a published app on a Windows Server 2008 machine. When instantiating the MapPoint.MapClass, I get the error:
"Your registry settings for this application were not copied correctly. To correct these settings, run Setup again for this application from the location where you originally installed it."
I am able to launch MapPoint just fine by itself outside of the app, the error only comes up when running the published app. We have multiple servers that clients run the app on, and the server running Server 2003 is able to launch MapPoint just fine. In addition, XP and Win7 machines also work fine. We also have a Foxpro application that also utilizes MapPoint's API installed on the 2008 server, and it doesn't have any issues.
MapPoint is included as a COM reference in the VS project referring to "Microsoft MapPoint 13.0 Object Library (North America) 8.3".
Looking online, I found a bunch of possible solutions, but nothing worked. I have tried:
Uninstalling MapPoint 2006 entirely and manually removing all entries from the registry, then reinstalling
Doing the same as 1 but then installing the trial of MapPoint 2011, resulting in the exact same error message
Disabling UAC
Setting MapPoint.exe's compatibility mode to Server 2003 and XP
Please let me know if anyone has any other suggestions.
it does sound like something is partially installing / being blocked. Is this a user issue? Ie. Can you install for all users?
it doesn't explain the MP2006 issue, but I would avoid the trial version for API work - the trial nag screen can be a problem. Eg. If you start the app hidden, the user cannot always see the nag screen to dismiss it.
You say you are instantiating a Map class. What about the Application (or _Application) class: you must have one of these to create the Map.
I have an error very similar to the one addressed in this question. I am trying to deploy a small c#/Xaml utility on 6 work machines. 4 of the machines run the utility successfully and 2 do not. All machines are windows XP and have .Net frameworks 1-4 installed (my app is compiled against 4.0 and all machines have both client and extended redistributables installed).
On running the utility, I get the standard "... has encountered a problem and needs to close." On viewing the error report contents, the problem seems to occur in System.Windows.Markup.XamlParse.
I have run .Net 4.0 online installer in "repair" mode and still I get the same problem. I have tried all the suggestions from the post linked above:
The file is deployed alongside a DLL which is present and correct.
UI cultures are identical.
All computers are up to date from Microsoft Update.
The assembly does not contain any external resources which are referenced in XAML.
I don't really know where to start with debugging this one. Any suggestions?
I would suggest setting up remote debugging on the machines that are having the problem and then adding this to the startup code:
while (!System.Diagnostics.Debugger.IsAttached)
{
Thread.Sleep(100);
}