I have a self-hosted WCF service (VB) residing on a server. This service has a method, which I call from another application, that is supposed to kick off a .cmd file which calls a 3rd party program.
My WCF has used both the old Shell() command and the Process() object. Both can call the .cmd file (located on the server's local drive). The .cmd file looks like this:
echo Before calling 3rd party app >> C:\HelloFubar.txt
cd C:\Program Files\Exstream\Dialog 6.1
Engine -CONTROLFILE=C:\Exstream\Development\LetterWriter\Control Files\Letter.opt
echo After calling 3rd party app >> C:\HelloFubar.txt
Now I know the .cmd file (saved as Letter.cmd) is firing because when I check the txt file after testing my app, the before/after statements have been written. However, the 3rd party application does not start.
Now the weird part -- if I double click the cmd file from explorer, the test statements are written to the text file AND the 3rd party application kicks off. Runs great.
I've double-checked the application and corresponding files to make sure NETWORK_SERVICE has permissions and my service is running under that account. So this does not seem to be a rights issue.
Any ideas?
Thanks,
Jason
Whew! Only took a week or two!
Note to self:
Self, you must make sure that any 3rd party applications kicked off from the NETWORK_SERVICE account are not trying to do things the NETWORK_SERVICE account does not have explicit rights to do. Like write to the registry, delete files and other tasks.
Try starting the service under an admins account, and make sure to use the servicePrincipalName attribute in the client when calling a WCF running under any account other than NETWORK_SERVICE. An example would be like this in the client's config file:
<endpoint address="net.tcp://myserver-2:8080/Service" binding="netTcpBinding"
bindingConfiguration="NetTcpBinding_IService1" contract="TCPService.IService1"
name="NetTcpBinding_IService1">
<identity>
<servicePrincipalName value="MyServiceReferenceName(InSolutionExplorer)\myserver-2"/>
<dns value="myserver-2.mydomain.local" />
</identity>
</endpoint>
Hope this can help somebody else out there!
Related
I'm trying call a WCF service (AX 2012) from my blazor app. I've added the reference under connected services (Visual Studio 2019) and the code generation worked. But when I call it the same way as in a WPF app I get the exception "target principal name is incorrect".
All information I can find refers to editing the app.config file. How can I fix this error using code changes or the dotnet core settings files? (I assume the appsettings.json)
I assumed authentication in the WPF app works simply by piggybacking off the logged in windows user but inspecting the config file I see this:
<endpoint address="net.tcp://server:8201/DynamicsAx/Services/WorkerSG"
binding="netTcpBinding" bindingConfiguration="NetTcpBinding_HcmWorkerImportService"
contract="ServiceAXEmployees.HcmWorkerImportService" name="NetTcpBinding_HcmWorkerImportService">
<identity>
<userPrincipalName value="svcax.aos#ourdoma.in" />
</identity>
</endpoint>
Been using the WCF Test Client for years now, testing externally hosted webservices that I consume.
I have often cursed about the inabillity to save a standard confuguration with settings about the bindings, as I for some of the methods needs to increse the maxRecievedMessageSize byond the standard 65536 - as well as occasionally other settings.
I would normally have to use the scvConfigEditor to update each time. But I lived with that.
UNFORTUNATLY - after updating to windows 10 and re-installing everything I can no longer edit the config file. Or I can edit, but the service will not reload with the new settings as it would before. I have tried editing the file manually also, and I have tried to refresh the service after saving both with the editor and manually..
Would anybody know the reason or a fix for this?
I had the same problem and compared my new installation to my old working installation.
First you have to deselect Always regenerate config when launching services from Tools->Option and exit WCF Test Client.
I found that the new installation was missing the AddressToConfigMapping.xml file in C:\Users\<user>\Documents\Test Client Projects\15.0\CachedConfig folder, which I had to create.
The content of the AddressToConfigMapping.xml file should be:
<Mapping>
<Entry>
<Address>http://localhost/TestService.svc</Address>
<ConfigPath>C:\Users\<user>\Documents\Test Client Projects\15.0\CachedConfig\Client.dll.config</ConfigPath>
</Entry>
</Mapping>
Then you can then edit the config file in scvConfigEditor and save the file to C:\Users\<user>\Documents\Test Client Projects\15.0\CachedConfig\Client.dll.config and replace the content of the address element with the service you are testing.
Now the saved configuration should be loaded, when you add the service in the WCF Test Client.
If you have to test multiple services, it is possible to add additional entries for different services with different configuration in the AddressToConfigMapping.xml file.
I have found another solution for this problem.
You can edit config file without svcConfigEditor using Restore to Default Config option.
Steps:
Run WCF Test Client and add service.
Right click on config file and select Copy Full Path.
Open folder with Client.dll.config.
Edit default.config.
Return to WCF Test Client.
Right click on config file and select Restore to Default Config.
This will replace Client.dll.config with default.config and re-apply settings.
Krimson's answer is correct. With Windows 10 and VisualStudio 2018 Community, the directory and mapping files are not being created. You can work around it by creating them yourself.
One additional point that I would like to stress is the value that needs to be provided for the Address field MUST be the service's metadata endpoint and not simply the service's endpoint. You typically can find the metadata endpoint in your App.config as
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:80/MyTravelAgency/" />
</baseAddresses>
</host>
In my service, the AddressToConfigMapping.xml file would look like
<Mapping>
<Entry>
<Address>http://localhost/MyTravelAgency/mex</Address>
<ConfigPath>C:\Users\Roger\Documents\Test Client Projects\15.0\CachedConfig\Client.dll.config</ConfigPath>
</Entry>
</Mapping>
The problem seems to be the saving behaviour of svcConfigEditor. Normally a file changed event would be raised but a change coming from svcConfigEditor raises an renamed event which is not handled by wcf test client. One way to get it to work is to reverse engineer wcf test client and extend the FileSystemWatcher to grab the renamed event. Another way
is to open up your favorite text editor and save the configuration file with a new blank line after you edit it. In this case the changed event is fired and the reload screen appears.
The configuration file can be found in %localappdata%\Temp\Test Client Projects\
To grab the renamed event you need to handle fileSystemWatcher.Renamed and to extend the fileSystemWatcher.NotifyFilter with the following settings:
NotifyFilters.Attributes | NotifyFilters.CreationTime | NotifyFilters.FileName | NotifyFilters.LastAccess | NotifyFilters.LastWrite | NotifyFilters.Size | NotifyFilters.Security
The related code to invoke if fileSystemWatcher.Renamed occurs is:
string fullPath = eventArgs.FullPath;
ServiceProject serviceProject = this.workspace.FindServiceProject(fullPath);
if (serviceProject != null)
{
this.TryRefreshConfig(serviceProject);
}
I have a web service that uses windows integrated authentication, and it works. But only after much trial and error it only finally worked with my config file endpoint section having an identity as follows:
<identity>
<servicePrincipalName value="host/servername" />
</identity>
Where 'servername' is the name of the IIS server hosting the webservice.
If I missed it out, IIS refused it (did not even get to the end point) with 'authentication error'.
However, when I recently needed to run a program on the same server as the web service this then failed with the same error and it worked only if I completely removed the identity or changed it to 'host/localhost'.
Can somebody explain why this is because I really don't understand what the servicePrincipalName/identity is really doing other than just working.
thanks.
The name of the user you wish the service to use (execute under) are placed as value for ServicePrincipalName.
You can have much simpler reference here.
I have one solution WCFSampleSolution and it has all my projects - Web Service, Client and Website. The structure is something like:
WCFSampleSolution
C:\WCFSample\Website
WCFService
WCFWebClient
I created WCFService project for my services. It contains IService1.cs and Service1.cs. Then I hosted the service in IIS. I did this by creating a website and adding .svc and web.config files to the website project. Then published it in IIS. When I run http:\MyMachineName\Website\Service.svc, it shows the service description. Then I create the web client that calls the webservice. I used the service reference to add the service. It calls a method of Service1. It works fine. But I amnot able to debug this program/setup. I verified the config files in WCFWebClient project and Website project and they have proper debug settings.
<compilation debug="true">
I put break points but control never goes to my seb service. I also tried attach process, but it also doesn't work. But I was able to debug one of my other WCF projects. The setup was little different. In that project I copied the .svc file and config in my web client and the debug works fine.
Please HELP!!
You are hosting your service on IIS so I am sure you must be attaching to w3wp.exe process. While trying to attach if VS built in web server is starting, then attach to that process as well.
What I find particularly easy is having two instances of visual studio open (especially if you use NUnit or doing anything to test out code). One will attach NUnit or whatever you wish, and the other will attach the w3wp.exe process. The easiest way is to:
1) Put a break point in the 1st instance of visual studio of the code right before it will hit the WCF service hosted on your machine.
2) Once the code stops at your breakpoint, set breakpoints in the 2nd instance of visual studio where you want to break then attach the w3wp.exe process.
3) Once you continue, the breakpoint on the service code should be hit.
It is sometimes easier to find the process id as well when attaching w3wp.exe. Using IIS, you can go to "Worker Process" and find the process id to attach for your Application Pool Name.
#user465876 - another approach that is less of a hassle can be found here: WCF can no longer step into a service that's locally hosted -- why not?
We have a WCF service that we recently switched from self-hosting to IIS-hosted. It needs to launch an executable using Process.Start(). This works fine when it's self-hosted, but when hosted in IIS, we get the error:
System.ComponentModel.Win32Exception: The system cannot find the file specified
We have the exe in both the bin directory and in the application root (next to the .svc file.) But, it can't seem to find the exe.
Any help would be appreciated. Thanks!
EDIT: I forgot to mention that we're launching using the following code:
Process.Start("LeakingWrapper.exe");
FURTHER INFO: Unfortunately, we don't have the option to switch the exe to a dll, because it is wrapping a third-party library that leaks memory. So, we have to put it into its own process to ensure our long-running WCF service doesn't leak!
Do you have the aspNetCompatibilityEnabled setting set to true? In that case, you'd have a HttpContext, which could try to use to call something like:
string exeFileName = HttpContext.Current.Server.MapPath("~/LeakingWrapper.exe")
Or: what if you specify the whole path to the EXE, e.g.
Process.Start("C:\yourServiceDir\bin\LeakingWrapper.exe")
Does that help at all??
Marc
marc_s answer is probably correct.
However, it could also be that the process cannont find the file because it does not have the rights to read the exe file.
To use the web service's path using HttpContext you must include the following line in your web service's web.config
<configuration>
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>
</configuration>`