Errors after install of latest version of adapters

Sep 14, 2011 at 12:16 AM


After getting the msi to install yesterday, I'm now getting errors on my development machine when I try to execute my package. I've built and tested locally, and the components work great. However, on the development machine I get a number of errors.

The component metadata for "component "xxxx" (1)" could not be upgraded to the newer version of the component. The PerformUpgrade method failed.

And a little later in the log:

The component is missing, not registered, not upgradeable, or missing required interfaces. The contact information for this component is "".

I've done a bit of reading to try and determine what the issue may be, but getting nowhere.

I've checked under C:\Windows\assembly, and can see both DLL's, version 1.2005.0.0, which I think means they have registered in the GAC. One weird thing on this machine is that there isn't a version of gacutil.exe available anywhere. Could that be an issue?

When I run Visual Studio 2005 on the machine, I can't see the entries under the toolbox items.

I've tried unintalling and reinstalling, but no luck.

Running SQL Server 2005, SP4 64 bit on Windows Server 2003 R2 SP2.

Help would be greatly appreciated!

Sep 14, 2011 at 8:48 AM
Edited Sep 14, 2011 at 8:54 AM

Are you upgrading existing components, or is this a new package?

If you have an old package, a previous thread mentioned this (

     Replace “933a2c7edf82ac1f” with “f4b3011e1ece9d47” in the package (public key)

I added this known issue to the FAQ page:

Sep 15, 2011 at 4:30 AM

Thanks for the response Kevin.

Local machine (which I inherited from previous developer) seems to have had an old version on it already. I installed the latest version, not uninstalling the old (didn't realise the old was there).

Checking c:\windows\assembly on the local machine, I can see the following:

  1. SharepointListAdapters / version 1.2005.0.0 / public key "f4b3011e1ece9d47"
  2. SharepointListAdapters / version 1.2005.0.0 / public key "933a2c7edf82ac1f"
  3. SharepointListAdapters / version / public key "f4b3011e1ece9d47"
  4. SharepointListConnectionManager / version 1.2005.0.0 / public key "f4b3011e1ece9d47"
  5. SharepointListConnectionManager / version / public key "f4b3011e1ece9d47"

The package I created on my machine is still using the old components, I've checked the public key in the dtsx file as per your link.

Checking c:\windows\assembly on the development machine, I can see the following:

  1. SharepointListAdapters / version 1.2005.0.0 / public key "f4b3011e1ece9d47"
  2. SharepointListConnectionManager / version 1.2005.0.0 / public key "f4b3011e1ece9d47"

This is why the package fails on the development machine. Incidentally, we have the old components on a test machine, and the package works fine there.

I asked a colleague to install the new version fresh on his machine - he did not previously have the new or the old version installed. He selected the Typical installation, and ended up with 2 versions of both the adapter and the connection manager in the assembly. Is this by design?

  1. SharepointListAdapters / version 1.2005.0.0 / public key "f4b3011e1ece9d47"
  2. SharepointListAdapters / version / public key "f4b3011e1ece9d47"
  3. SharepointListConnectionManager / version 1.2005.0.0 / public key "f4b3011e1ece9d47"
  4. SharepointListConnectionManager / version / public key "f4b3011e1ece9d47"

Additionally, he can not see the toolbox items, and cannot add them from the Tools > Choose Toolbox Items menu. Does he need to manually register these components with gacutil.exe? Or should we manually choose the install location?

We're basically stuck with a situation where I can develop with the old components (i.e without the connection manager), and they can be pushed to our existing test/prod machines, but not the dev machine. However, we're upgrading 2005 > 2008 this year, and I need to have the new components on my machine. Would really like a way to clean out the old version, and get the new version installed correctly. Is it possible it's a problem with the x64 version? I also noticed in my "choose toolbox items" dialogue that most of the items there are listed as coming from c:\Program Files (x86). Should I install there instead?

Sorry for the essay, hoping you can help.

Sep 15, 2011 at 4:54 AM

Thought I should add, on the development machine (which has the new version), I did try to amend the package and change the public key. However, because the version I developed with seems to be from before the connection manager existed, I get the following error:

"in the connection manager collection, Connections, of "component "xxxx" (1)" does not have a value for the ID property. Verify that the ConnectionManagerID property of the runtime connection object has been set for the component."

Sep 15, 2011 at 5:30 AM

Ok, a little more progress.

After installing, we copied both dll's from the "C:\Program Files..." location, to the equivalent location on "C:\Program Files (x86)..."

The components were then visible in the Choose Toolbox Items dialogue, and we could see the source/destination components, and the connection manager option.

I think this means we can wait until we build a new 2008 machine, install the new version on that machine, overwrite the old version in "C:\Program Files (x86)..." on my local machine, fix the packages developed with the old components, and deploy from there.

I'd be curious to know why I had to manually move the dll's to the x86 location?

Sep 15, 2011 at 8:10 AM

Wow, a lot in that essay.

First of all, the and 1.2005.0.0  versions are fine, that means that the installer installed the 2005 and 2008 components (2008 is the version).

That error you mentioned on the dev machine is really just a warning for the reason you stated. You just need to create a SPCRED Connection Manager and associate it to your source/destination adapters. Once you do that, it sounds like it is picking up the new components and I'd hope it would be working.

You should not have to register anything with gacutil... you ARE correct about the program file location though. And the installer should absolutely be installing the components there. I am not sure I understand why it would not install them in that folder.  To help me track this down, did it not install any files in teh c:\Program FIles (x86)\...\90 AND \100? or was it just one of the versions that didn't have the files in the location? Note my next question after that will be to the registry key to find out why the one i used was not the right location.

Note.. the GACed components are used during Runtime. The components in the Program FIles (x86) are used during VS Designer (as Visual Studio is 32 bit)

Sep 15, 2011 at 8:36 AM

Glad you could make sense of all that :)

Can absolutely confirm that the installer only installed the dll's in the "C:\Program Files\..\90" location, and nothing in "C:\Program Files(x86)\..\90".

I take it you're expecting both?

To be certain, I'll do a more thorough search tomorrow morning to see if they've been placed elsewhere unexpectedly, and will let you know.

Sep 16, 2011 at 7:30 AM

Ok, did a full search today, and on the development machine (that only has 2005 installed), the dll's were only placed in the "C:\Program Files\..\90" location.

What would you like to me to look for in the registry?