I have been trying for days to get a custmized data extension that I
built using the example at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/RSDSetEx3.asp
to be recognized by the report server on a Windows 2003 box. It is
recognized and works well on my development machine. I have followed
the recommended steps outlined below:
1) Create an entry in RSReportServer.config:
<Extension Name="Dataset"
Type="DataSetExtension.DSXConnection,RSCustomData"/>
DatesetExtension.DSXConnection is the correct namespace (I customized
it), RSCustomData.dll is the name of the assembly which has been placed
in the following folder:
C:\Program Files\Microsoft SQL Server\MSSQL\Reporting
Services\ReportServer\bin
2) Create a new code group entry in rssrvpolicy.config. This
potentially could be the source of the problem, as I have received
conflicting recommendations on where in the code group heirarchy I
should place the new entry. I am currently placing it under the
"Url="$CodeGen$/*" entry
3) Restarted IIS and restarted SQLServer. Is there any reason why the
PC should have to be restarted? When does RSReportServer.config and
rssrvpolicy.config get loaded?
I then created a web service client and called the ListExtensions
method of the resportservice.asmx web service. It only lists the
original 4 data extensions - SQL, OLEDB, ORACLE and ODBC. After
dozends of attempts over several days and after reinstalling Reporting
Services, I still am having no luck getting the data extension to be
recognized on the server. Even though it works great on the dev
machine and I can step through the code without a problem.
Bonus question: One post mentioned the
<securityPolicy>
<trustLevel name="RosettaSrv" policyFile="rssrvpolicy.config"
/>
</securityPolicy>
<trust level="RosettaSrv" originUrl="" />
entry in web.config as a potential source of the problem. Searches on
google for RosettaSrv turn up almost nothing. Does this have any
effect on giving permissions to custom assemblies?
Thanks in advance for your help.I worked with Microsoft and got the problem solved. It was a
permissions issue on the assembly that I copied from my development
machine to the reporting server. We used filemon.exe to show that the
assembly was not being loaded. Other notes from Microsoft:
"Resolution:
By adding read & execute permissions to the Report Server directory for
the Users group, and allowing parent permissions to propagate to the
custom dll in the bin directory, the report server was able to load the
custom dll and display the custom data extension. In resolving this
case we used FileMon from SysInternals.com.
No comments:
Post a Comment