Archive for July, 2009

The DataSourceID of ‘QuickLaunchMenu’ must be the ID of a control of type IHierarchicalDataSource. A control with ID ‘QuickLaunchSiteMap’ could not be found.

July 12, 2009

This Error message happens after I changed the Web.Config.

whatever I want to Modify the Web.config (some strange character, Case of character), it still the same thing.

My solution:

copy the Web.config from other Port, put it in current Port, and add in the “SPXmlAdminContentMapProvider”.

then the error message disppeared.

Advertisements

[MOSS开发]:webpart在部署时应该注意的地方

July 8, 2009
 http://www.blogjava.net/zhaijianhui/archive/2009/05/16/270967.html
由于近期项目的需要,我开始学习MOSS编程,刚开始接触的时候觉的特别的别扭,觉的没有自己全新创建的web application来的自由,但是MOSS还是有很多优点的,这篇我先说下自定义webpart的部署问题。
    如何创建webpart我并不想在这篇中讲,具体我会另外写一篇关于webpart开发的文章。

    MOSS中的webpart与普通.net控件的不同点:

       1:webpart一般都是以类库的形式出现,它是没有前端可视化页面的,类似于asp.net中的自定义控件。

       2:两者继承的基类不同:

           1):asp.net控件的基类:System.Web.UI.WebControls.WebControl;

           2):webpart的基类:System.Web.UI.WebControls.WebParts.WebPart;

       3:两者生成的文件不同,下面几个是asp.net控件所不包含的:

           1):密钥文件;

           2):每个 Web 部件都应有一个 .webpart 文件,还有一个描述 Web 部件的 XML 文件。这是webpart独有的特征。
       4:MOSS中的webpart部署并不像asp.net网站中的一样,控件和网站程序放在一起然后部署就行,我总结以个几点应该注意的地方:

          1>:首先把生成的webpart的dll文件复制到sharepoint网站对应的目录中,而程序集的部署分以下几种方式:
             1):bin目录,在创建一个web application时,会选择一个端口,此时在IIS中就会创建一个对应端口的网站目录:Inetpub”wwwroot”wss”VirtualDirectories”20983,在这个目录下面有两个文件夹:_app_bin,bin,将编译好的程序集放进任何一个目录即可;

             2):全局程序集缓存:全局程序集缓存使各个应用能够共享程序集,它会被.Net运行时自动加载。它的位置在:[System Drive]”Windows”Assemply。 因为它会强命名程序集,所有具体开发时不推荐这种方式。

             3).指定目录,参考第一条,bin,_app_bin,这两个文件夹都可以用来部署程序集,MOSS还支持指定目录方式,这需要在Web.Config中进行配置。在<configuration>节下进行配置:

   <runtime>
      
<assemblyBinding xmlns=urn:schemas-microsoft-com:asm.v1>
         
<probing privatePath=bin;_app_bin;CustomBin />
      
</assemblyBinding>
   
</runtime>

           小结:其实上面的方式一和方式三是同一原理,实际上可以说是两种方式。还有一点就是如果想手工复制程序集到sharepoint网站的bin,这里有两种简单的方式:

                    1:选择项目-属性-生成-更改输出路径到sharepoint网站的bin即可;

                    2:选择项目-属性-生成事件-增加生成事件:

copy $(TargetPath) E:InetpubwwwrootwssVirtualDirectories20983bin

          

           BIN目录的优点和缺点:

                   1:优点。它是一个单独信任位置,默认的,代码访问安全级别非常低。如果想让webpart正常运行,一般都需要开发人员显示的提升BIN目录的信任级别。一个BIN目录对应一个web application,这样我们可以为不同的web application创建不同的独立代码。

                  2:缺点。如果想在另外一个web 应用中应用此webpart,则需要重新部署。

          全局程序集缓存的优点和缺点:

                  1:优点。它是经过签名的程序集,信任级别最高,属于完全信任。因为它部署于全局位置,所有能够被所有web应用所共享。

                  2:缺点。由于它是完全信任,所以它失去了相应的防御措施。

           2>:设置特殊安全属性,如果是采用部署到bin的方式,则会存在安全性问题,如不做处理则会出现如图一的情况。

 

             原因:默认情况下bin 目录的代码访问安全权限很低,对存储的webpart具有特殊的安全约束,Web 部件在执行时不会自动授予完全信任代码权限。我们可以手工来设置这些属性。

                   1:在web.config文件中有一个配置节trust level,是控制信任级别的,我们可以更改此配置节来提升bin目录的安全性:trust level=Full。

                   2:在生成的程序集文件 assembly添加一句 [assembly: AllowPartiallyTrustedCallers()]

             小结:上面方法一般性地提升了信任级别,所以会授予您可能不需要的任何新权限,这样就不如另一种创建新信任策略文件的方法安全。创建一个新的信任策略文件,将 web.config 文件指向该新文件。这种方法较为复杂,但是可以更为精确地设置 Web 部件的权限属性。[引用MSDN],

          3>:注册控件。控件的注册离不开web.config文件,找到SharePoint节点,在最下面添加如下信息: (Assembly,Version,Culture,PublicKeyToken的查看方式可以通过.Net Reflector。 )

<SafeControl Assembly=WebParts.Samples, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5 Namespace=WebParts.Samples TypeName=* Safe=True />

    </SafeControls>

 

          4>:导入到Webpart部件库。网站操作-网站设置-修改所有网站设置-库-web部件-新建-选中刚才创建的webpart-点击“导入库”-在页面中添加webpart即可。

  总结:

       本文总结了些webpart部署时对于新手的一些困惑,虽然没有比较深入的地方,但是学会部署webpart是MOSS编程的基本功。希望大家指点。

  注:

      本文所讲的环境均为MOSS 2007

How to manually remove a webpart (SPS WSS 2003)

July 2, 2009

by Servé Hermans | 5:13 PM in Sharepoint 2007 Other |
Somehow, I was not able to deinstall webparts using the stsadm -o deletewppack -name command. This happened after we upgraded a webpart with a new version.

To manually remove the webpart:
1. Access the configuration database and locate your webpart. Write down the ID number (eg 5.) and delete the entry from the WebPartPackages table
2. Go to the InstalledWebPartPackages table and delete all the rows which match the specific ID (in our case the ID was 5)
3. delete all dwp files that match your webppart name in every website _wpcatalog folder for every front end server. Leave all the other dwp files untoched.
4. now you can check if the deinstallation was succesful by stsadm -o enumwppacks -farm.

Eventually you can reinstall the webpart package.