Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

GAC wpresources problem?

  Asked By: Connor    Date: Apr 25    Category: Sharepoint    Views: 1275

If I have one usercontrol application. I need to exclude the path. In
the GAC implementation where do I need to create a virtual directoy
either in SPS site directory or _wpresources folder?

Got stuck with the GAC installation. I have copied the webpart
images,javascript resources in _wpresources(local_drive\program
files\common files\microsoft shared\web server
extensions\60\wpresources) and all the dependency dlls also I
compiled with strong name keys i.e. I could see these dlls in
C:\windows\assembly folder with publickeytocken. I have written a safe
control of all these dlls in web.config of portal site.
Its giving run time error, I could able to deploy the webpart
successfully. But drag and drop gives error. Please whats wrong with
the process?

One more thing I found if I create a bin folder in portal site
directory, and copy all the dlls works fine. But GAC installation
should not contain any of the assemblies in Bin folder right?

Can anybody gives tips about this solution?



7 Answers Found

Answer #1    Answered By: Jasper Hatfield     Answered On: Apr 25

I've experienced inconsistent results. The global install of STSADM is
certainly broken. Just how broken is hard to define. Thus far I've had a
difficult time  defining the steps necessary to overcome the brokenness.
However, it is overcomable as I've done it many times. Just not

For a while I thought the steps were to fully qualify the assembly in
the DWP and manually delete, redeploy, and reset IIS on each change to a
Web Part. However, that didn't work the last time I demoed it. Arrrrgh.

Answer #2    Answered By: Rashawn Hopper     Answered On: Apr 25

One of the problems with the global install for STSADM is where it references
the assembly from. You can look in the windows/assembly folder  to see which
assemblies are in the GAC, but this does not mean that the dlls  are actually
stored there - if you look at the properties for each one you can see where the
original CodeBase really resides. When you install a webpart by using the
global install of STSADM, it references the codepath to your local profile,
which for obvious reasons will not work for everyone -- It may work for you, but
then others try to use your webpart and it doesn't work. If you create  an
install file (.msi) you can then install the dll into the program files
directory (Microsoft's recommendation) and then when you install it to the GAC,
it should work better. (That is the setup of your purchased webparts)

Back to your original question... your virtual  folder should most likely be
created in the site  root (general recommendations made by others).

Answer #3    Answered By: Horace Coffey     Answered On: Apr 25

Thanks monty. If there is a problem  with stsadm tool, Is it ok to use
GACUTIL.exe to install the assemblies  on GAC?
I want to give the flexibility to the user whether they want to
install the webpart on GAC or BIN directory. Here I am
facing problem is after installing the webpart in GAC, suppose if I
uninstall the webpart and if I try to install the webpart
in BIN directory, its giving  problem. its(dlls) not removing from the
GAC other than the webpart dlls...(dependency dlls)

Answer #4    Answered By: Rigoberto Beard     Answered On: Apr 25

You can use GACUTIL or drag  the dll from the Program Files folder  to the
Assembly folder, and it will install and set the codebase to the program files
location. I'm not sure, but you may have to check that the applicaiton pool
account has access to the DLL (Program Files).. I haven't done it for a while,
so I don't remember if this was a requirement.

I have not found  a way to really clean webparts out of the system if they don't
uninstall properly.. I've gone and deleted them from the GAC, deleted the
resource folders, deleted them out of the web.config, but STSADM still says they
are installed. If anyone has a way of completely cleaning these left-overs out
of the system, please let us know.

Answer #5    Answered By: Alphonso Mckay     Answered On: Apr 25

As you said, stsadm.exe tool always keep the Codebase location for
assembly as Local_folder. which may not have permissions to others.
I thought I can follow the second approach which you have sent. How do
I add the permissions on those assemblies  when the dlls  are installed
program files\bin directory.

But I am not sure how do I check the following link which you have indicated.
"you may have to check that the applicaiton pool account has access to
the DLL (Program Files).. "

If you can provide me how do I check/add this permissions, that would
be really great!.

Answer #6    Answered By: Daron Oneill     Answered On: Apr 25

Did you also delete the Dashboard Web Part (dwp) file from the

Answer #7    Answered By: M Juarez     Answered On: Apr 25

Yes, deleted the dashboard webpart also from wpcatalog.

Didn't find what you were looking for? Find more on GAC wpresources problem? Or get search suggestion and latest updates.