I have a WCF service which is hosted in a WinForms application. This WCF service calls a COM component written in ATL on Visual Studio 6. This works just fine on Windows XP. However the COM component fails on Windows 7 when calling GetFileAttributes. It says the path does not exist even though it does. It is a mapped network drive. The only reason I can think of for this is that The WinForms app which hosts the WCF service has to right clicked and Run As Administrator. I am then assuming the COM component effectively gets the same raised priveleges and therefore the mapped drive which existed under the user logged in to the machine no longer exists as far as the application is concerned.
Is this a valid assumption and if so what are my options for solving this?
On Windows 7 (and equivalents) you loose mapped drives when you run as administrator. That's because you basically switch to another login token, and the network drives are mapped only to the non-admin's.
There are a few ways to overcome this, see discussions here and here.
Also, there's a registry setting (not mentioned on those links) that links the two tokens. See KB article about EnableLinkedConnections, a discussion about using it.
Related
I am building a client-server application, this is all running locally on my computer whilst I am developing the system. However, eventually I would like to deploy the server-side part of the application to a server to run 24/7, enabling client applications to connect and consume the service at will. What I would like to know is, when I come to doing this would I simply just install the server-side application on the server, hit run and that's it? That just seems... well not right (to me), is this the way it is done? or is there a lot more to it? I imagine there is, but I can't seem to find any content on this subject.
FYI - the server is a self hosted WCF application.
You'd want to take your program's executable, support dlls and config files and drop them into a folder. Then create a Windows Service to run the program; if you don't use a Windows Service, the program will only run while you're logged on, which isn't good. As a Windows Service, a reboot of the server will bring the program back online even if you're not logged on.
Here's a knowledge base article from MS on how to make a windows service.
http://support.microsoft.com/kb/251192
If you're program is compiled as a DLL, then create a small .exe program to run it (a wrapper) then deploy the program as described in the article.
Good luck.
I need to debug a Sharepoint WCF service that is deployed for Sharepoint 2010. However, a colleague needs to debug another Sharepoint service deployed on the same phyical machine. If we debug at the same time strange things occur with the Visual Studio debugger. For example, his debugger would break at breakpoints I have set, or I am seeing exceptions raised by his code. Mind you, we are debugging different services in different solutions. From the information I have gathered so far, this behaviour is like this because there is only one w3wp process per application pool that both the Visual Studio Debugger instances attach to.
So I figured I should try running my service in another applicaion pool to get a different w3wp.exe to attach to. Here is what I tried, but I am not sure, if what I attempted makes any sense, please clarify:
IIS Manager shows that there are two different Sharepoint application pools (excluding the one for Central Adminisitration) and a Site for each. So I tried deploying my service using the other application pool by setting the deployment location to the URL of the other site. However the virtual _vti_bin directory of the service still maps to the same physical directory ...\Web Server Extensions\14\ISAPI\. Deploying from Visual Studio works, but getting a ServiceReference does not. Trying to open <url>/_vti_bin/MyService.svc/MEX shows an error page telling me that therer is already a binding instance associated to the URL. So, I guess this is either not the way to do this, or it is simply not possible to "isolate" services in this way. I am very hesitant to just trial-and-error with IIS Manager or Sharepoint Central Administration settings, because I feel I don't know enough to avoid screwing things up.
Could someone tell me how I can solve this?
The URL you specify when deploying in Visual Studio can be misleading. If you have a sandboxed solution, it gets deployed to this location. If you have a farm solution, it gets deployed centrally and it uses the URL to figure out what application pool to recycle. If you have web application specific settings in the solution i.e. safecontrols), these will be applied to the web application hosting the URL.
The _vti_bin is available to every site in the whole farm; as is _layouts. Since a service will be exposed through multiple URL's (one for each site) the SharePoint team has created custom factory classes to make this possible. Check out one of the built in svc files, and you will see that it uses a special factory class. Use this in your svc file to expose your service in all sites.
As for the debugging, it's never a good idea to have multiple developers using the same machine. If you really want to do it, I suggest using two web applications with different application pools. That way each developer has their own process to attach to. If you use different accounts for the application pool, it makes it easier to find the correct one in the 'attach process' dialog.
We have a WCF service hosted in IIS that currently calls a VB6 DLL to do part of its job. This works fine, but we can't deploy the service to a 64-bit target environment without configuring IIS to run it in a 32-bit worker process.
I am currently investigating ways around that restriction. Porting the VB6 DLL to .NET is not possible for various reasons, so I created an ActiveX EXE wrapper around the DLL in VB6, so that the service can run in 64-bit and the VB6 parts in 32-bit.
When I tested the service I got this error:
Type: System.UnauthorizedAccessException
Message: Retrieving the COM class factory for component with CLSID {9AE7303B-D159-43F6-B1A5-52D297581820} failed due to the following error: 80070005.
After some Googling I found that this is due to either:
Calling an MS Office component
DCOM permissions not being configured
NTFS file permissions not allowing read/exec access to the IIS worker process identity (ASPNET in my environment)
Of these:
Definitely not applicable
Also not applicable; I am not hosting the EXE in DCOM or COM+, just a simple COM out-of-process activation
This looks likely; however, I checked the permissions, and NTFS reports that the Users group (which ASPNET is a member of) does indeed have read/exec access to the file
I tried calling the EXE from a unit test fixture, which is executed in my admin-level account rather than the IIS worker process account, and it worked fine, so the error is definitely something to do with permissions. I'm not sure what to do next. Can anyone suggest things I can check?
My test environment is Windows XP / IIS 5.1
UPDATE:
The IIS virtual directory is configured for Anonymous+Windows access; the WCF service uses only Anonymous authentication, the Windows authentication is for the VS debugger. Task Manager reports that the aspnet_wp.exe process is definitely running in the ASPNET account.
I explicitly granted Read and Execute access to the ASPNET and IUSR_<machine> accounts on all the COM exes and dlls involved. This made no difference.
I explicitly granted Local Launch and Local Activation access to the ASPNET and IUSR_<machine> accounts on the relevant interfaces in the DCOM configuration. This made no difference either.
As I see it I have 3 options:
Keep trying to get this working somehow.
Go the whole hog and host the EXE in COM+.
Give up. Tell users that the WCF service must be configured to run in a 32-bit app pool on 64-bit Windows.
Your error is an Unauthorized access exception. Therefore, the problem is probably rights related.
You could check what the security context of the 32bit worker process is.
Also check your event log, they may be information there about what account is being used.
I may be SOL on this but I thought I would give throw it out for possible solutions.
I am writing a computer access control service to help me control my kids' computer use. Plan on open sourcing it when I have it working. It is written in VB.Net and needs to work on XP through 7.
I am running into all sorts of security and desktop access issues on Windows 7. The service needs to run as admin to execute the NetSh command to disable the network. But I cannot interact with the desktop from the service so I IPC to a UI to handle other stuff, but I still cannot detect from the service if the desktop is locked. Argghh!
I could get it all working from a hidden windows form app if I could just lick the one piece that needs admin permissions: disabling the network.
It does no good if a kid logs on and denies the popup asking if the program should run as administrator and he says no. Also windows 7 will not start a program set to run as admin using
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Anyone know how to get this working? Or have an outside the box solution?
I wish I could provide some references, but I'm failing at my google-fu right now... but I'm pretty sure UAC doesn't apply to services. If you implement your program as a windows service application instead of a (hidden) windows forms application, and set it up to run for your kids' user accounts and not your own, that should work.
UPDATE
Found this on google, haven't played with it at all. Looks sound though... basically, CreateProcessAsUser to run the forms app from your service app that's running as administrator.
Greetings,
we have to following problem.
Our application is deployed using ClickOnce. Everything is running fine and application is able to connect to the wcf service. The problem occurs when application is installed on FRESH XP machine without .net Framework and Windows Installater (that were selected in ClickOnce prerequities).
Application downloads .NET Framework 3.5SP1 and windows installer but then it cannot connect the the server. Reboot after install does not help.
The strange is that this application has been installed on 10 xp machines and 4 of them can connect to the service without a problem
Are there any dlls referenced in your application? You might want to check them (Under project's Properties\Publish tab\Application Files button) see if you missed to include the needed dlls or files.
alt text http://www.freeimagehosting.net/uploads/e8ff221e20.jpg
We ran into this and were forced to reinstall .net on some machines no idea why though.
This is a shot in the dark but have you tried depends.exe and see if it can profile what is happening.
Also Take a look at this blog and get a crash dump and see if you can use it to at least tell you what is complaining the loudest.
What do you mean when you say 'cannot connect to the server'?
a. The machine cannot connect to the install location and therefore the clickone app is not installed?
b. The app installs (along with the pre-requisites) and starts fine. Then it is unable to connect/communicate with your WCF services.
I presume (b) I just wanted to clarify.
What happens when you ping the machine the services are on from one of the failed install machines? Also what happens when you put the service url into a browser on one of the failed install machines? Can you see the wsdl?
Obviously your deployment package works because it works on those other machines (I assume it IS the same package all machines are installing?), therefore I doubt you are missing any dll's as a ClickOnce app should include all dll's it needs (sometimes you do need to tell ClickOnce explicitly to include).
Last question is, when the app tries to call the service, exactly what exception is it getting back?
I just remembered something which has caught me out in the past with some machines being unable to connect but others can...especially 'new' machines.
Check this file:- C:\WINDOWS\system32\drivers\etc\hosts
Check the contents on a machine that works and one that doesn't. We have some IP to machine name mapping going on that on new machines is not set and so the new machines cannot find the servers.