select 4.0 package on select 4.1

[KPChow]

I have a package developed using select 4.0 which I can install on clients running select 4.0. If I try to install on clients running select 4.1, I receive an error while attempting to register my package using spregpkg. The error includes "Could not load file or assembly 'SoftPro.Select.Shell, Version=4.0.0.0" ... "The located assembly's manifest definition does not match the assembly reference"...

Do packages developed for select 4.1 need to be developed using select 4.1?

[BobRichards]

Yes. Your package targeted version 4.0.0.0 of SoftPro's DLLs. You must now target the Select 4.1.0.0 DLLs by installing a 4.1 SDK and rebuilding the package. As long as you do not change your source (or package version number), you will not need a new package license.

[KPChow]

Thanks for the reply. Is 4.1 backwards compatible with 4.0? Could I use a 4.1 SDK and deploy to both select 4.1 and 4.0?

[BobRichards]

The issue is that the Select DLLs have a fully qualified assembly name that includes their version (either 4.0.0.0 or 4.1.0.0). You can probably use the 4.1 SDK to build either version but you would have to change the project references to point at a single version of Select DLLs at a time - and they should be the same build version that is used in your production environments.

[czentman]

I am trying to "upgrade" my package that created and had a package license and all worked in the 4.0 environment. The 4.1 sdk and 4.1 select program were installed on this system. I tried to delete all the dll's that were select dll's, and add in the 4.1 dll's of the same dll names. For some reason, it keeps going back to the old dll's and then showing errors on the imported dll's. I think that's what it's doing because after I re-imported the new 4.1 dll's they say they have a runtime version of 4.0.30319 which is what it used to be, although the version field on the bottom says 4.1. Is this normal? I'm assuming not, or that I have to be doing something more since when I attempt to compile, I get errors from all my imported dll's. What may I be missing? Do I have to first unregister?

[BobRichards]

The Runtime version is the .NET version that VS thinks should be adequate to run the DLL. The Version property is the version of the DLL. You should ignore the displayed runtime version. If Version is 4.1.0.0, you should be pointing to the correct DLLs.

[KPChow]

Where does spregpkg get the dll version numbers from? I am using all 4.1 dlls, yet I am getting 4.0 errors.

I am using the 4.1 sdk.
My references are to select 4.1 dlls.
I can see 4.1 dlls as detected dependencies in my install project.
I can archive my msi and see the 4.1 dlls
I can even see references to 4.1 in my dll while viewing it in a text editor.

C:\Program Files (x86)\SoftPro\Select>spregpkg /m:register /p:SoftPro_RecordingE
xpress_Plugin.dll
Could not load file or assembly 'SoftPro.Select.Shell, Version=4.0.0.0, Culture=
neutral, PublicKeyToken=3834c39820615aaf' or one of its dependencies. The locate
d assembly's manifest definition does not match the assembly reference. (Excepti
on from HRESULT: 0x80131040)
Could not load file or assembly 'SoftPro.Select.Shell, Version=4.0.0.0, Culture=
neutral, PublicKeyToken=3834c39820615aaf' or one of its dependencies. The locate
d assembly's manifest definition does not match the assembly reference. (Excepti
on from HRESULT: 0x80131040)
Could not load file or assembly 'SoftPro.Select.Shell, Version=4.0.0.0, Culture=
neutral, PublicKeyToken=3834c39820615aaf' or one of its dependencies. The locate
d assembly's manifest definition does not match the assembly reference. (Excepti
on from HRESULT: 0x80131040)
Could not load file or assembly 'SoftPro.Select.Shell, Version=4.0.0.0, Culture=
neutral, PublicKeyToken=3834c39820615aaf' or one of its dependencies. The locate
d assembly's manifest definition does not match the assembly reference. (Excepti
on from HRESULT: 0x80131040)

[BobRichards]

It looks like your project is still referencing the Select 4.0 DLLs during your package build. Are there other projects in your package that might be referencing the old DLLs?

I have found that even though the VS Project does not specify a specific DLL version, it has trouble updating the information. I sometimes have to delete the Select DLL project references then add them back by adding the 4.1 DLLs.

[BobRichards]

Is it possible that you are using the "spregpkg.exe" from the Select 4.0 SDK instead of the Select 4.1?

[KPChow]

spregpkg is part of the client install which is 4.1 and my package is also 4.1. I was able to get my package registered by extracting the contents of my msi and replacing the plugin dll in the select client with the dll extracted from my msi. I had been experimenting yesterday with both the client and the plugin and it looks to me like there is a ghost in the machine with the 4.1 client. The 4.0 client plugin dll is reinstalling itself when I install or uninstall the client (not plugin) or when I install my plugin by either double clicking on the msi or via the cli (C:\Plugin>msiexec /i "SoftPro_RecordingExpress_Plugin_Install.msi" This is even though the 4.0 client plugin not being contained within my msi. If I install using the cli like this:

C:\Plugin>msiexec /a SoftPro_RecordingExpress_Plugin_Install /qb targetdir="c:\P
rogram Files (x86)\SoftPro\Select"

The correct version (4.1) of my plugin dll is installed.

I have written up a 13 page document with plenty of screen shots demonstrating this behavior. There probably is a record of the 4.0 client plugin stored in the registry which is being used to re-install this dll.