Thanks Trent

Peter

Really they should both be the same assembly so as long as these are in-sync it wouldn't really matter.  But probably the GAC would be the easiest so if you drag a DLL fix from the forum or something of that nature it will be looking at the right location.

Trent,

Alright, I now understand that there are no easy tricks, but can you clarify where ideally I should be referencing Strataframe ".dll"s from, the GAC or the "Common Files"?

Thanks

Peter

Welcome to the new "DLL Hell"

Yeah, we have fought this non-stop as well.  There are several things that you can do.  One thing that you can do is try to direct all of the references to the C:\Program Files\Common Files\MicroFour\StrataFrame folder by removing the references and then selecting that specific file.  However, there are times that it will try to automatically select the GAC version, so if this happens you may want to temporarily remove the SF assemblies from the GAC while you are selecting the others.

If you do change the vbproj file, then this is generally something that you only have to do once per project.  So this really isn't as bad as you may think.  Sometimes you just gotta do what you gotta do.  This is something that I have posted to Microsoft before...coming up with an easy solution to pulling from a common location...and to be consistent!

Trent,

Thanks for the hints.

I did find a couple of references set to copy local in our solution, but more disturbingly, with the paths, an assortment of "C:\Windows\assembly\GAC_MSIL\..." and "C:\Program Files\Common Files\MicroFour\StrataFrame\..."

Looking at the properties for the references there are only two that I can change: "Copy Local" and "Specific Version".
So I was able to fix the few "Copy Local" stragglers.

With the path I found by setting "Specific Version" to False I could ensure the path was pointing to "Common Files", but setting it to True would sometimes point it to the GAC, but often cause no change. I tried deleting the reference and adding it back in again from the ".Net" tab, but this didn't appear to have any effect, and there was no where in that process that I could see that would allow me to set a specific path to the GAC.

I decided to delve a little deeper and look at where the references are defined in MyProject.vbproj with a text editor. I found that where the reference was defined as follows, Setting Specific Version had no effect on the path:

    <Reference Include="MicroFour StrataFrame Base, Version=1.6.0.0, Culture=neutral, PublicKeyToken=99fe9917f71608a7, processorArchitecture=MSIL" />
   
However if the reference is as below, changing Specific Version to True causes the path to reference the GAC.

    <Reference Include="MicroFour StrataFrame Base, Culture=neutral, PublicKeyToken=99fe9917f71608a7, processorArchitecture=MSIL" />

So, I can set the specific version property to false everywhere to consistently use "Common Files", but to consistently use the GAC, which I understand is what you recommend, something more is required. If I have to I'll edit all the .vbproj files in our solution, but I'd rather not do that and I'm hoping you'll able to me what simple technique I'm overlooking.

Peter

When they released the GAC with the first blush of .NET, this was supposed to releive the age ol "DLL Hell"...in truth, it just took everything to a new level of "DLL Hell."

Yeah, this is something that we have all struggled with and it isn't always the same assembly.  In our meical software, there is an assemby that loves to hang around and it difficult to get "cleared out."

But here are a few tips.  What usually happens is that the reference has the Copy Local property set to True and it may get copied local (even when in the GAC) from time to time.  So if you perform a Clear Solution and then a Rebuild Solution, this will generally clear out those items.

Next, here is a place to look to ensure things get updated:

1. C:\Program Files\Common Files\MicroFour\StrtaFrame
2. \bin folders of your projects that reference the assembly
3. GAC

When you are having these types of issues, it is almost a 100% guarantee that there is an older assembly out there somewhere, and getting it into the GAC won't always fix the problem.

Another tip, be sure to see where the project is pulling the reference from.  To do this, select the reference, right-click and go to properties.  You will see the path that is being used for the reference...ironically, this isn't always the GAC and when this happens, there is a %99.9 percent of frustration and course language

But this will generally steer you down the right path of knowing where the problem is.

Actually, Peter's colleague (ie me) was in the midst of an upgrade to DevExpress 8.1, having moved to VS2008 and Strataframe 1.6.5 over a week ago (you'd think we never talk).

Further to that I've had everything working after a reboot (being able to successfully open every form in our solution) several times this afternoon, only for it to go wrong again (every form failing to open in the designer with a problem with the GradientFormHeader). So I'm not confident that Peter's fix is permanent. Having said that, I used drag and drop to copy the Inherited UI into the GAC and haven't tried the gacutil yet.

Peter

Hi Guys,

A message from the trenches....

Just a bit of a extra info that may or may not be useful. Once I dropped the dll into the GAC the problem I originally had disappeared but there was another 'funny' problem with references to the DevEx.GradientFormHeader. This was in an old and shakey part of the system that I was getting into again (reports related). Anyway, I presumed it was a new issue and carried on. Around this time I deleted something I shouldn't have and this caused its own set of issues and, simultaneously, my collegue was moving over to VS2008, SF 1.6.5. which again had its own problems and he became involved in my efforts to retried my deleted form and also had the GradientFormHeader problem.

The bottom line is that we came to think the source of all our problems was the Inherited UI dll but everything looked to be ok. The copy in the GAC had the same date/time as the copy downloaded from the SF web site. During this time we had both rebooted about a million times so that wasn't an issue. In the end I dug out gacutil.exe and did the install int the GAC using that but that made no difference and, for some reason, I rebooted and, what do you know, everything was fine....

I've no idea what's been going on but my recommendation for putting a dll into the GAC is:

Start the VS2008 command prompt: Start>VS2008>Tools>Command Prompt

Enter the command: gacutil /i "C:\Program Files\Common Files\MicroFour\StrataFrame\TheDLLToInstall"

Then reboot.

Cheers, Peter

Yup, Peter nailed it   Thanks, Peter!

Hi,

You need to be Admin to do that - presuming you are not and/or your account is the new Vista 'Admin, not quite..' type then right click on Explorer and click "Run as Administrator" then do the drag and drop.

Cheers, Peter