Hello all,

On a Windows 2000 Server machine, I have an ASP.NET 2.0 web service which calls the methods of MapPoint throught interop. Everything worked fine in MapPoint 2004 until I upgraded to MapPoint 2006. I get the following errors consistently:

1. System.Runtime.InteropServices.COMException (0x80080005): Retrieving the COM class factory for component with CLSID {31851F82-AFE6-11D2-A3C9-00C04F72F340} failed due to the following error: 80080005

2. System.UnauthorizedAccessException: Retrieving the COM class factory for component with CLSID {31851F82-AFE6-11D2-A3C9-00C04F72F340} failed due to the following error: 80070005

Thanks for all your help,

Dawa

Can anyone else help with this - I have exactly the same problem.

I had everything working with MapPoint 2004 (Europe) but now nothing will work with 2006 (and I have tried going back to 2004 but now that worn't work).

I have tried the following (which originally worked to get MapPoint 2004 set up with ASP.NET 2005):

1) Run MapPoint and agree to the licensing terms.
2) Check that map loads and zoom around.
3) Close MapPoint.
4) Run MapPoint.exe /registerserver (using the correct folder path)
5) Open Component Services, find and expand DCOM Config, find the MapPoint entries in the list
6) For each MapPoint entry:
i) select Properties
ii) select the Security tab
iii) under Launch and Activation Permissions, select the Customize option then click the Edit button
iv) add the local ASPNET account to the list, tick all the boxes and click OK
v) repeat the above for the Access Permissions section
vi) click OK to exit the Properties dialog
7) Add a reference to the MapPoint COM Object in your .NET project.

That worked for 2004 but 2006 consistently gives me the error "
Retrieving the COM class factory for component with CLSID {15A40122-24D2-4FDB-8155-5F65FCE7017F} failed due to the following error: 80080005."

Can anyone help us?

OK, this may be of help.

I have found a workaround to this problem. I spent a day writing a simple Windows Service that registers a TCP Channel and exposes a 'Manager' object via remoting that will return a MapPoint instance.

Getting the Manager object in a test client app worked, but when it returned a MapPoint object it just hung, then timed out after a minute or so.

So I tried all sorts to get it working, thinking it was a remoting issue.

Turns out it was much much simpler than that - MapPoint was trying to pop up an EULA agreement dialog, but it never showed on the desktop. I turned on 'Allow service to interact with desktop' for my windows service and restarted it. Next time I ran my test app, up pops the EULA - I clicked I Agree and never had any problems (or further popups) after that!!!

And this is all despite me running MapPoint normally and agreeing to the EULA. Maybe it popus up an EULA for each new user that opens MapPoint for the first time?

If the same timeout or system hang is happening to you, and you check your running processes and see MapPoint.exe in the list, then I bet this is what is happening - the EULA is invisibly sat somewhere in virtual land waiting for a user to click I Agree.

Hi,

Thanks for feedback. So if I understand right you clicked 'agree' for the EULA with the MP desktop, but if you run your application as NT service then it needs again the 'agree' on the EULA but then from the NT service. Is that correct understand ?

Hi Wilfried,

Yes - that's correct! I think the EULA pops up for every user the first time they use MapPoint on the machine, including if you run it in code with no GUI. Thinking about it, this would be true if being deployed as part of the server-side code for a website (runs under the ASPNET account) or a Windows service (runs under the LocalSystem account).

Hope that helps!

Paul.

Hi Paul,

thanks. I put it in the FAQ, this is very interesting.

I am using the MapPoint object in a web service. How do I go about agreeing to the EULA, to avoid this error since the web service is running on the server with no GUI? Thanks

Hi cybergroove,

I was stumped as to how you could do this, but have found some articles which may provide you with a solution.

Since you are writing a webservice, I'll assume that it will run under the local ASPNET account, which does not have interactive desktop abilities. However, this article may help to remedy that:

Unable to Start a Process from ASP.NET

Failing that, you could add security impersonation to your webservice code. This would allow your webservce to start and run as normal under the ASPNET account, then you could switch to a known user account (you could set one up specifically for mappoint use if you wanted) just before you instantiate your mappoint object(s). Note that you may have to be switched to that account in each method call that accesses your mappoint object or there may be exceptions thrown.

There is a good article on adding an Impersonation class here:

Role Based Security in .NET

Note that with the latter option, you could create a local/network account specifically for your mappoint webservice, but you would need to log into the target deployment server under this account, run mappoint, agree to the EULA (and dismiss the registration popup if I remember correctly!) then exit mappoint. This will complete the EULA agreement for that user. Then you can log back in as the normal user of that server and install your webservice.

Hope that makes sense - this is just theory but I have used these techniques in other situations with success so I hope that gets you up and running.

If you find a working solution then post it here and we can tick the box for people writing webservices with mappoint as well!

Kind Regards,

Paul.

Hi all,

Some additional information that might help.

I've just installed a fresh copy of MapPoint 2006 Europe on a machine and ran Process Monitor whilst agreeing to the EULA. It turns out that agreeing to the EULA creates the following registry entry:

HKCU\Software\Microsoft\MapPoint\13.0\EUR\
Name: EULA
Type: REG_DWORD
Value: 0x0000001 (1)

Now I'm going to try the same technique with a service running under the local system account, and see what registry entry gets set.

Paul.

Hi again,

OK, some information that might just clinch it.

The key that gets set for the MapPoint EULA on other accounts seems to be in the registry section HKEY_USERS\. So for the Local System Account this is HKEY_USERS\.DEFAULT\Software\Microsoft\MapPoint\13 .0\EUR\EULA (Type: DWORD Value: 0x0000001 (1)).

So for any other account you run the MapPoint object under (other than the current user account which would be HKEY_CURRENT_USER), there would need to be an entry under HKEY_USERS for it.

So, for example, I wanted to debug where the registry setting was made for the ASPNET account.

So, first I changed my MapPoint Windows Service to run under the ASPNET account - in order to let ASPNET run this, I had to first set a known password for the ASPNET account (don't worry, you can reset this back to being system controlled by running "aspnet_regiis -i" afterwards).

Next, I added the ASPNET account to the DCOM configuration - in XP this is:
Component Services
Computers
My Computer
DCOM Config
Microsoft MapPoint
(right-click / Properties)
Security tab
Launch and Activation Permissions
select Customize option
click the Edit button
Add the local ASPNET account to the user names list
select the Local Launch and Local Activation checkboxes
click OK
Access Permissions
select Customize option
click the Edit button
Add the local ASPNET account to the user names list
select the Local Access checkboxes
click OK
click OK

Next, I started my service to see what happened - looked normal, but eventually got a timeout error in the Application event log because the MapPoint object failed to register with DCOM in a timely manner. This is because the EULA has not been agreed to for this account.

I looked in registry and found the new entry in HKEY_USERS which is for the ASPNET account. It is a GUID type of entry rather than just simply saying ASPNET! Under this I added the necessary entry for agreeing to the EULA (see above).

Now, I restarted my service and bingo! MapPoint runs fine with no errors in the event log and I can access my service.

The key to this is adding the DCOM entry for the account you want to run MapPoint under, and finding the correct key in the HKEY_USERS part of the registy to add the MapPoint EULA entry under. You don't need to change the password for the ASPNET account if you are running it under this - I just did this for the benefit of working out what was happening under the hood, so to speak.

Anyhows, post here if you find this solves your particular issue.

Kind Regards,

Paul.