From referring to the posts regarding 2.5.2 install kits, it is supposed to do the install to the user’s My Documents folder. This answered the first question as to why the install would default to the local Documents and Setting folder location.
I have a couple other questions:
Are we supposed to run the install kits logged in as each user who might use it? I am running into an issue where I have to install for each user on a machine in general. The software does not show up in the Add/Remove of any users other than the one whoe installed and the .NET registry entries used to resolve any references to your assemblies are now located under HKEY_CURRENT_USER. So, if I install as Administrator and then log in as another user, that user cannot use or resolve references to GoDiagram components. If I install the kits again as that user, it works.
Are all the assemblies supposed to be in the GAC? That would solve problem 1) probably. It appears that Northwoods.Go.dll is in the GAC and can be resolved by multiple users without installing multiple times. However, Northwoods.Go.Xml.dll, Northwoods.GoWeb.dll, Northwoods.GoWeb.Xml.dll do not show up in the GAC and cannot be resolved by anyone other than the user who installed the software.
I have ran into this issue on both Windows XP and Windows 2003 Server.
Are you installing the GoDiagram Win kit for .NET 2.0?
For 2.5.2 we have changed the kits so that one does not need to be an administrator in order to install, or in order to enter unlock codes. Changes were also needed for Vista installation, except that HTML2 help registration still requires administrator privileges – but even if you’re not an admin, the rest of the installation is OK.
I suppose if a different user wants to use GoDiagram, they can just copy that directory tree. I think a few things would be missing:
no Programs menu items under the Start menu
no registration of GoDiagram assemblies for Visual Studio's Toolbox customization
no integrated HTML2 help in Visual Studio -- can do this manually or just use the HTML1 help: GoWin.chm
no evaluation license keys -- can run LicenseManager and enter "eval" as the unlock code for GoDiagram Win (or "evalweb" for GoDiagram Web)
2) No assemblies are put into the Global Assembly Cache. We do this for .NET 1.x, but this is no longer necessary for .NET 2.0.
So your situation suggests that we ought to document how to register HTML2 help manually, and that we ought to automatically make sure there are at least evaluation licenses when one runs the LicenseManager. Although since users can install on their own, I'm not sure this would be terribly useful.
Both GoDiagram Win for .NET 2.0 and GoDiagrm Web for .NET 2.0 are being installed.
So, this essentially means that the product needs to be installed logged in as the user where they will use Visual Studio. I tested and it does work to install again as another user. In my case, I installed on a build machine as administrator, but forgot the the automated build service runs as a different user. So the builds failed due to an inability to resolve the references. This was solved by logging in as automated build service user account and installing again.
This can also be a problem where you have a laptop that you use sometimes in a domain/network environment and sometimes not. In that case, you might want to log in as a local user when not connected to the network. For this case, your software has to be installed twice.
In the missing items you should also add the registration of the lib directory for .NET assembly folders … used by MSBuild and Visual Studio to resolve references that cannot be found in GAC.
Rather than copy files, etc., it appears to be easier to just install as the other user :).
Lastly, three assemblies are in my Global Assembly Cache: Northwoods.Go (v 2.5.2.2), Northwoods.Go.Instruments (2.5.2.2), Northwoods.Go.Layout (2.5.2.2)
This is a pretty big install change, esp. for a dot release, and should have been mentioned in the Release Notes at least.
I don’t understand how those assemblies got put into your GAC, but it shouldn’t do any harm to have them there.
You’re right – although the release notes mention the change in location for the directory, it didn’t mention the other changes, which happened later in the development cycle when the contents were already frozen but Vista release candidate builds seemed to become available every week.