The report definition for report ''ILMSHeader'' has not been specified (rsErrorExecutingSubr
We have localmode reports implemented as plugin DLLs.
The reports run fine on our dev boxes and display the one or more subreports we use.
When we run the same reports on the same OS etc but non-dev boxes, we get this error.
We've verified that the subreport(s) (along with the main report) are embedded as resources in the DLLs.
We've also added test code that streams the subreport RDLC off disc (that works, no exceptions thrown etc), and we've also added code that uses Reflection to pull the subreport RDLC out of the assembly (that works as well, no exceptions etc.)
Yet we are steadfastly getting this error.
The subreport processing event never fires, and we've turned on ALL exceptions in the debugger and no exceptions are firing anywhere close to this code.
Any thoughts on what else we can do, what else might be causing this, how to generate more meaningful diagnostics, anything at all?
[968 byte] By [
eldelo] at [2008-1-9]
Often when this happens the report is deployed but as an empty definition (I know you said it's embedded but still) -- check to see if that has happened.
What deployment method are you using, FWIW?
>L<
Thanks for the suggestions... I'll go take a look at this... I've been comparing *ReportViewer* dll versionj across platforms and so on this AM.
BTW, assuming there is something wrong with the embedded subreport, how to we remedy that? FWIW I'm skeptical that loads of the subreport RDLC from both the embedded resources *and* a disc file could both end up consistently bad... Then again, stranger things have happened... :-)
For now we're not deploying, per se...
The latest shipped version of our flagship suite shipped with the Winforms (localmode) RV install-media/installation rolled up in the app suite install.
So the runtime support is there for any install of our latest version.
Beyond that, we added support for RV-based report DLLs to our report plugin interfaces.
The DLLs are detected (via presence in a reports folder) at startup and loaded dynamically.
So when it comes right down to it, deployment consists of copying the Report-This-Or-That.Dll file to Report-This-Or-That.Plugin on the target machine + folder. That part has worked smoothly across mulitiple releases and contrinues to run smoothly.
I had another thought...
exactly how are the subreports referenced in your embedded reports? Because it seems to me (guessing) they might need the DLL qualifier in them -- and perhaps they don't have that? Also are they in the main project directory or elsewhere?
>L<
The DLLs are built as C# .Net DLL projects.
Everything (dataset, main report RDLC, subreport RDLC's, plugin interface code, the whole mess) is all compiled into each DLL.as a standalone project.
The subreports are specified within each project in the subreport controls properties (the subreport being on the main report.). The combobox to make the specification only shows the one subreport as being available, so there's no other options available at that point.
The DLL/plugin code and some of the UI is dependent on/shared with the main app (obviously, since they are plugins), but as far as the datasets and reporting stuff goes, it's all standalone and compiled into the one DLL.
The RDLC's are marked to be compiled as embedded resources, and they show up in ildasm with what appear to be appropriate namespace-scoped names and with non-trivial data lengths. Since the main RDLC loads, I don't believe it's an issue with the namespacing. We tried spec'ing one of the subreport RDLC's with the DLL/projects' namespace scope, that didn't make any difference.
The one thing I just noticed is that when we pull the subreport RDLC out of the Assembly resources with Reflection and write it back to disc (using a StreamWriter), the file ends up zero length.
We're not sure just yet if that's because the resources are somehow bad or because of the code we're using to write the resource to the Stream and ergo out to disc. I'm going to add a pull/write of the main report (which does render properly) and see if it writes out as a zero length file as well.
We wrote some code that is able to demonstrably retrieve the resources if such are reachable at all.
In the case of the main report, we can extract it and it appears well formed etc.
In the case of the subreport, the string/data is coming back zero-length, no matter how we try to get at it and even with the code that can successfully retrieve the main report.
It seems clear there's an issue with the embedded resources, but how do we proceed from that? In other words, how do we solve the issue and/or work around it?
>>n the case of the subreport, the string/data is coming back zero-length, no matter how we try to get at it and even with the code that can successfully retrieve the main report.
That's actually what I expected...
I followed up with these questions, don't know if you saw them:
>>
exactly how are the subreports referenced in your embedded reports? Because it seems to me (guessing) they might need the DLL qualifier in them -- and perhaps they don't have that? Also are they in the main project directory or elsewhere?
<<
>L<
I aplogize... I saw your questions and attempted to answer them, though apparently not in a form you recognized or that addressed your query...
Everything is self-contained in the one DLL which is also a VSS C# .Net Project unto itself.
Excepting references to external assemblies and interfaces, all the source, the report RDLC files, the hosting form, the form_load (etc) code, the entire class/form code and methods etc, the dataset(s), the subreport processing event, any code necessary to create/retrieve/fill/munge the datasets, the UI code (form, error/messaging dialog, etc), etc ad nauseum are all part of the project, which is therefore self-contained. All of that code is in the one Project main diretory.
The form itself and some utility classes/methods derive from a base class/form that we created to encapsulate common code and form interactions/methods, but outside of that it's all there and it's all self-contained and standalone.
The subreport is specified to the subreport control in/on the parent report by opening the parent report in the VS Designer, selecting the subreport control, right clicking to invoke the Properties dialog, and selecing the subreport (minus the RDLC extension, which the dialog will not display) in the Subreport combobox.
This has always worked in the past.
I've tried to get a peek at what the Properties dialog, it's Subreport combobox, and the automagic code (generation) behind it are doing, but so far that's all a black box to me.
When you say we might need to use the DLL qualifier, are you referring to somehow prefixing the subreport name with the DLL's namespace (scope)?
We tried something similar... The subreport is named ILMSHeader[.rdlc]... We tried prefixing the subreport name with Reports.Stuff.This.That (the DLLs namespace) in the subreport Properties dialog, so that the subreport name looked like
Reports.Stuff.This.That.ILMSHeader, but it still wouldn't load at runtime.
Hi there,
Sorry -- I've been away -- IAC what I was missing from your previous answer was the bit about the main directory...
>> when you say we might need to use the DLL qualifier...
To be honest I haven't done this in the properties dialog or anything like that, so I don't know for sure. But I have used embedded reports and loaded them dynamically (I keep meaning to write a blog post about this among other dynamic reporting stuff and I just haven't had any time for this recently). And I know I have to do something like this when I load embedded report resources explicitly; the name has to be fully qualified. My impression has been that this only worked properly when the report was in the main subdir.
The only thing I can think of is that you're doing something different than I am in terms qualifying by "the DLLs namespace". When I say "fully qualified" as a resource, that isn't by namespace, it's by the name of the file in which the report is embedded as a resource. The report isn't really in your namespace at all, any more than an image resource is in your namespace. It's in a file.
I have *really* been pushed for time, and I'm sorry that I can't sit down and work this out -- but I'm figuring that you have worked with image resources and can see what I'm saying.
If I have an executable named MyEXE.exe and I want to load a report that is in it, I have to do something like:
Code Snippet
Me.ReportViewerInstance.LocalReport.ReportEmbeddedResource = "MyEXE.MyReport.rdlc"
... okay? So I'm figuring that your subreports have to be referenced this way as well. Again, I have not done this in the properties window and I also think it only works in the main project directory.
Hope this helps and once again sorry for the delay.
>L<
Lisa, please do not feel you have to apologize, in my estimation you are far and away the number one contributor and help in these parts. You are to be commended and thanked and if you can't get back to a particular person or issue - or can't solve it - them's the breaks!
I see what you're saying about the qualifier as being file-based instead of namespace-based. Thanks for clarifying.
The interesting thing is that *we* are now able to programmatically access the embedded rdlc as a resource, it's just that the ReportViewer can't.
And unfortunately we don't get to intercept that call, nor does the ReportViewer generate any diagnostics (except that it can't load the subreport. Gee, how helpful, as if that wasn't obvious in itself.)
We can however generate reports successfully that use the same connstr and datasets and rdlc's that run as standalone exe's and will be attacking the problem from that angle (get the reports running again as standalone exe's, then try to repackage them as loosely coupled DLLs, and hopefully and finally get them back into plugins.)
For the life of me I don't understand why ReportViewer technology providers (both MS RV and Crystal) anally refuse to allow the consumers (creators of web stuff and/or apps) access to meaningful diagnostics, no matter what goes wrong nor how one attempts to access them nor what methodology one employs.
To be honest this was what finally pushed us away from CR... the total lack of support (unless one wants to spend thousands of dollars) and the pathetic diagnostics.
Well, now here we are trapped behind the same lack of diagnostics in the MS RV stuff.
>>The interesting thing is that *we* are now able to programmatically access the embedded rdlc as a resource, it's just that the ReportViewer can't.
Well... this might make sense, depending on where the reportviewer DLLs are. Are you copying them locally (IOW are they in the same location as your resource files that contain the embedded reports)?
I know you listed the elements of your deployment process earlier, I just want to clarify this.
It seems to me that you might want to copy the report viewer DLLs locally just to control potential version problems, so you may already be doing this -- in which case yes I agree with you, I don't understand why you can "see" the embedded rdlc and the reportviewer can't.
But if the reportviewer dlls are elsewhere on the machine, it makes sense to me that they cannot.
Thanks for continuing to think out loud <s>.
>L<
When you ask about the reportviewer Dlls, are you asking about MS's ReportViewer Dlls themselves, or our Dlls?
If you're asking about our Dlls, then yes it's all basically local. The report and subreport are in the same Dll as is the bulk of our dll/plugin code.
It occured to me late last week that some of the plugin base class's/form's code is in a seperate DLL. That code ends up on the plugin's side of the call stack/invocation at runtime but remains in a seperate DLL.
Assuming that's the case it might explain the situation, if the report dll with the embedded resources was starting an invocation that ended up executing code in the base class/form's dll that in turn was somehow triggering the subreport load in that context rather than the report dll itself.
I'll have to dig a little deeper into this today, it's on the top of my list.
I was asking about the reportviewer DLLs from MS (I believe there are 3 required), not yours <s>. They are the ones that need to invoke the subreport. Right?
However, the fact that you have a separate DLL for part of the code might also be a contributing factor, I suppose. Can you do a simplified test to check?
>L<
I just tried every scoping (name decl, whatever) on the subreport's name I could think of (namespace, dll name, etc etc.)
I explicitly tried the name string that we're getting back as the name in the assembly resources at runtime.
No such luck.
To my mind it must come down to either the RV runtime looking for either a DLL or EXE to extract the subreport resource out of (our report plugins are renamed *.plugin), or to our refactored code confusing the RV runtime.
I'm going to squirrel away the current incantation of our work and try to sync back to the less-well-architected solution that at least seemed to work. It's a bit messier in terms of implementing individual reports, but if it works that's a pretty strong argument in it's favor...
So... did you or did you not try copying the MS reportviewer dlls locally into your deployment set of files? <s> Not to be weird about insisting on this but ... ? You've gone to a lot of trouble here, and this shouldn't be that much of a stretch. Plus, as I said, you might have other reasons to do this (to avoid versionitis).
>L<
