Feed Icon  

Contact

  • Bryant Likes
  • Send mail to the author(s) E-mail
  • twitter
  • View Bryant Likes's profile on LinkedIn
  • del.icio.us
Get Microsoft Silverlight
by clicking "Install Microsoft Silverlight" you accept the
Silverlight license agreement

Hosting By

Hot Topics

Tags

Open Source Projects

Archives

Ads

WebPart Resources

Posted in SharePoint at Monday, October 18, 2004 10:44 AM Pacific Daylight Time

I spent the whole day working on upgrading some web parts to fix some bugs and to make sure they meet some new web part standards that we have at my work. One of those standards is that the assembly must be signed. If you've built web parts then you probably know about the PartImageLarge element in the DWP file (if you don't, the rest of this post probably won't be too interesting). In the PartImageLarge element you specify the path to the image for the web part which shows up in the Add Web Part dialog.

Now, if an assembly is not signed, your resource path will look like:

/wpresources/[AssemblyName]/.

This is pretty simple so my DWP files had this hard coded in them for each image. However, once you sign a web part assembly your resource path suddenly changes to something much more cryptic:

/_wpresources/[AssemblyName]/[AssemblyVersion]__[PublicKeyToken]/

Okay, so it isn't terribly cryptic, but enough to make me want to figure out a better way than to hard code it. So, I do what I usually do when I need to figure out something like this: I look at what MS did in their web parts. After a quick look at the Office 2003 web part DWP files I found my answer. It is actually very simple. Just replace the path with _WPR_ and SharePoint will work its magic. So the PartImageLarge element get changed to:

_WPR_/someimage.gif

Wow! The cool thing is that this works no matter what your path is.

Update: BTW, I forgot to add you can get this same coolness when you're programming webparts. It is the ClassResourcePath property of the WebPart class (you can reference it in your class via base.ClassResourcePath). Somehow I missed this cool property so I wanted to pass this along so you didn't.

 

Tuesday, October 19, 2004 6:02:00 AM (Pacific Daylight Time, UTC-07:00)
Very cool. I was wondering if you would be willing to share your web part development standards? We are working on our own and would be very interested in sharing those with you if you would like.
<br>
<br>Thanks for all of your informative blogs
<br>
<br>Mike
<br>mike@mikelinster.com
Tuesday, October 19, 2004 10:44:00 AM (Pacific Daylight Time, UTC-07:00)
You're welcome! Unfortunately the only requirements I have gotten is that the web part assembly be signed and that it be distributed in an MSI file.
<br>
<br>If I come across others I'll try to post them...
Tuesday, January 18, 2005 6:20:00 AM (Pacific Standard Time, UTC-08:00)
Useful tip indeed.
<br>A little more information you may need to know about that _WPR_:
<br>The _WPR_ is extended to the absolute path to the specified instance of the web part.
<br>If your web part is in a sub site, or sub area, you will get:
<br>/[path to the area]/wpresources/[AssemblyName] and not
<br>/wpresources/[AssemblyName].
<br>This may definitely come to a surprise to you (at least it did surprise me), as it makes it more difficult to access the web parts resources from the code behind: if you try to use the url, you will get an access denied because of the double hop/ kerberos-NTML authentication. And if you want to find the file path from the url, you'll run into trouble as Page.MapPath doesn't work!
<br>If anybody who has a good solution (other than parsing the string), I'm listening.
Thursday, January 27, 2005 6:21:00 AM (Pacific Standard Time, UTC-08:00)
The trick is to access the resource via http and not directly.
<br><a target="_new" href="http://www.schaeflein.net/blog/ClassResourcePathGotcha.aspx">http://www.schaeflein.net/blog/ClassResourcePathGotcha.aspx</a>
Comments are closed.