Versioning issue

Is the 1.0.81 version in the GAC at all? If so you might want to remove it. Also if you are using VS 2005 you might want to open the project in Notepad. Look at the references area and see which build number is indicated for Shared/WinUICore and maybe update that manually. Then reopen the project and rebuild the it.

1.0.81 is in the GAC alongside 1.0.82. I'm unable to uninstall it from the GAC because it says there are other applications that require it. But the only apps I have installed are SyntaxEditor 3.1.212 and UIStudio 2.0.72, both of which use 1.0.82, so I'm not sure how to clean up the reference.

That's odd... here's a possible backdoor way to remove that reference. I believe you can remove the registry key that is tracking it. Use regedit to go to this key:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Assemblies

In there are a bunch of path keys. Find the ones for Shared/WinUICore build 81 and then maybe try to remove them. You might want to backup your registry before trying this of course.

It was actually under HKCU, but yes, I was able to delete those values and delete 1.0.81 from the GAC. Now when I try to run the program I get the error 'Could not load assembly...' 1.0.81 for both dlls. There is no reference to it in the application. I opened up the project and the solution files in Notepad and there are no references to the older version. The references in the app are set to 1.0.82 and 'Use Specific Version' is set to true. I don't understand how it is still holding on to the older reference.

Hmm... perhaps try deleting your obj folders for your project. Sometimes that seems to cache things.

Every time I reinstall UIStudio 2.0.72, it puts both 1.0.81 and 1.0.82 common files into the GAC. Not sure why that would be the case. Also, now I'm unable to view my form that contains UIStudio elements because the designer error shows:

Type 'ActiproSoftware.UIStudio.NavigationBar.Office2003NavigationBarRenderer' does not have a constructor with parameters of types WindowsColorSchemeType.

Microsoft support is limited because after running the Assembly Binding Log Viewer it shows that its UIStudio itself that is requesting 1.0.81. I'm attaching the log files that were captured. Of particular interest is that the 2.0.72 version of UIStudio is calling the 1.0.81 assembly, as shown in the Calling Assembly section of the Pre-bind info. It seems that after upgrading I'm calling a method or doing something that calls 2.0.72 to dynamically attempt to bind to 1.0.81.


*** Assembly Binder Log Entry (9/22/2006 @ 11:56:53 AM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable C:\Documents and Settings\skb\Desktop\bin\Debug\ScriptDeploy.vshost.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = USERNAME
LOG: DisplayName = ActiproSoftware.WinUICore.Net20, Version=1.0.81.0, Culture=neutral, PublicKeyToken=1eba893a2bc55de5
(Fully-specified)
LOG: Appbase = file:///C:/Documents and Settings/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = vshost.exe
Calling assembly : ActiproSoftware.UIStudio.Dock.Net20, Version=2.0.72.0, Culture=neutral, PublicKeyToken=be939c973e8cb8a6.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: ActiproSoftware.WinUICore.Net20, Version=1.0.81.0, Culture=neutral, PublicKeyToken=1eba893a2bc55de5
LOG: GAC Lookup was unsuccessful.

And here is the second instance.

*** Assembly Binder Log Entry (9/22/2006 @ 11:56:53 AM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable C:\Documents and Settings\Desktop\bin\Debug\ScriptDeploy.vshost.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = USERNAME
LOG: DisplayName = ActiproSoftware.Shared.Net20, Version=1.0.81.0, Culture=neutral, PublicKeyToken=36ff2196ab5654b9
(Fully-specified)
LOG: Appbase = file:///C:/Documents and Settings/Desktop/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = ScriptDeploy.vshost.exe
Calling assembly : ActiproSoftware.UIStudio.NavigationBar.Net20, Version=2.0.72.0, Culture=neutral, PublicKeyToken=be939c973e8cb8a6.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: ActiproSoftware.Shared.Net20, Version=1.0.81.0, Culture=neutral, PublicKeyToken=36ff2196ab5654b9
LOG: GAC Lookup was unsuccessful.

[Modified at 09/22/2006 12:17 PM]

Hi Marianne,

I just tested the build 72 install and it only installs build 82 of Shared/WinUICore. It doesn't install build 81. I don't think our WiX installer is even set up to allow the possibility of installing two versions of them, other than a .NET 1.1 native build and a .NET 2.0 native build of the same build number.

I also verified in the project code for UIStudio that they reference build 82 and not 81. We haven't had anyone else reporting any similar situation so I'm not sure what is going on in your computer's situation.

If you want to write us an email, maybe we can set you up with a preview of the next maintenance release to see if that makes a difference.

One question based on your bind info... do you have a config file set up on your machine that might be forcing build 81 (based on this info line)?
LOG: Post-policy reference: ActiproSoftware.Shared.Net20, Version=1.0.81.0, Culture=neutral, PublicKeyToken=36ff2196ab5654b9

I've discovered the problem-- there are two separate UIStudio 2.0.72 setups. I had to actually open the failing one with an MSI viewer and to my surprise the shared files are all 1.0.81 which was leading to all of my problems. I downloaded it again from the site and opened it and of course it was set correctly. That being the case it is kind of obvious what happened. Whoever uploaded the original 2.0.72 version realized at some point that the incorrect versions of files were in the setup and recompiled the setup. However, no mention of it was made anywhere. This is extremely disappointing in that this has cost me a lot of lost time. In the future, I would strongly recommend that if you post actual release versions of products and have to update the setup that you make mention of it somewhere so that people aren't chasing their tails for no reason, and maybe even update the setup version to 2.0.72a or something to indicate that a change has been made.

I guess I'll have to make it a future policy to inspect all Actipro setup files before installation. What is most disappointing is that this is something that could have been easily avoided. In addition, when I first posted the problem, that should have immediately set off a light in somebody's mind to say, "Oh yeah, when we first posted the setup it had the wrong files". And then days later, when I posted the log definitively showing that the 2.0.72 files were using 1.0.81 files it should set off an alarm. Instead, I get to spend 6 days with forum posts, support calls to Microsoft, etc. Extremely disappointing.

Please tighten this up.

[Modified at 09/27/2006 08:48 AM]

Hi Marianne,

We don't re-release official final builds with the same build numbers. So once build 72 is out there for the public, then it is out there and any other changes to it we will make a new build number. We specificially do that to avoid the problem you encountered.

I am guessing that in your case, perhaps we made a fix for you in which we might have supplied you a "preview" of the build 72? When we send those previews out we usually indicate in emails that they are probably not the final official release and that you should update when the final one comes out.

In any case, we'll make sure we continue to not upload official releases with the same build numbers and in any situation where we supply you a preview release, please always ensure you get the official release when it is available.