none
Expression host RRS feed

  • Question

  • Report viewer, in local mode, windows forms. Several reports.

    Working for about 3 months, on around 20 PCs. However, on a new pc, when the report is about to load, I get a message

    'An error occurred during local report processing.'

    Which doesn't mean much. However, on two of the reports I get a message about

    'C:\Documents and Settings\theusername\Local Settings\Temp\expression_host_abc12324334435435435 in use by another process'

    On all the other PCs, there are no expression_host files. There are several on this problem PC. Genarated when my report program is run. Why are these files there?

    I search this forum, and saw a post about expression host and using ExecuteReportInCurrentAppDomain. So I added that line.

    ReportViewer1.LocalReport.ExecuteReportInCurrentAppDomain(System.Reflection.Assembly.GetExecutingAssembly().Evidence) Me.ReportViewer1.RefreshReport()

    But it made no difference. On the other hand, I had not done any ExecuteReport code before, so I didn't think it would make a difference.

     

    Any ideas how I can stop the expression hosts files being generated and get the program to run?

    Friday, July 20, 2007 8:30 AM

Answers

  • Btw, I never posted the actual error. When the report is launched, I get a message where the report should be:
     
    An error occured during local report processing.
    The definition of the report 'Main Report' is invalid.
    An unexpected error occured in Report Processing.
    The process cannot access the file 'C:\Documents and Settings\kathleenl\Local Settings\Temp\expression_host_d2085148d7064e868cb98926c54e851e.dll' because it is being used by another process.

     

    Thursday, August 2, 2007 9:40 AM

All replies

  • Any difference in the version(s) of .NET available on this new pc?

     

    Any difference in how the reportviewer DLLs are made available to it?  (Do you redistribute stuff with your program to do this, and how do you do that?)

     

    FWIW "Expression host"  sounds vaguely WPF-ish -- is this "new pc" truly new, and is Vista on it?

     

    >L<

    Saturday, July 21, 2007 3:29 PM
  • The new PC used the same Clickonce install as the other PCs. The install has the reportviewer included.

     

    The pc uses Windows XP, same as the other PCs.

     

    The version of .NET is 2.0.50727.832

    The versions on the working pcs is 2.0.50727.42

     

     

    Monday, July 23, 2007 8:29 AM
  • Also, the report viewer on all pcs is 2.0.50727

    I find this using the following code:

    Dim Version As String

    Using R As New Microsoft.Reporting.WinForms.ReportViewer

    Dim A As System.Reflection.Assembly = R.GetType.Assembly

    Version = A.ImageRuntimeVersion

    End Using

    Monday, July 23, 2007 2:09 PM
  • It does sound like WPF is installed, since the version is different, and with that error... you said it was a new PC, but could it have different patches applied. Can you take a look in Programs installed and see anything about this?  It might give you a clue as to exactly which DLLs were updated.  If there is an incompatibility of this nature, it's important to find out and report it, I'm sure...

     

    FWIW I happen to be running on Vista at the moment and my .NET version is NET 2.0.50727.312.  Which is lower than yours on the both working and non-working PC, right?

     

    As far as the version of ReportViewer goes... there couldn't possibly be a different version *also* available... like the "new PC" has visual studio, or something like that?  Probably not.

     

    >L<

     

     

    Monday, July 23, 2007 3:10 PM
  • I wonder is the incorrect version of report viewer being reported. Do you know of a way to find the version manually?

    The error only occurs when report viewer is run, displaying datagrids etc works fine.

    Tuesday, July 24, 2007 8:08 AM
  • I guess it could be wrong.

     

    Try some code like this (may not be exactly right but I'm taking it from something with a slightly different purpose, should be nearly what you need....

     

       

    Code Snippet

             Dim x As System.Reflection.Assembly = _

                   System.Reflection.Assembly.GetEntryAssembly(), _
                    y As System.Reflection.Assembly = Nothing

               For Each objDepAssembly As System.Reflection.AssemblyName In _
                   x.GetReferencedAssemblies()
                   Try
                     y = System.Reflection.Assembly.Load(objDepAssembly.FullName)

                    ' do some stuff here to check what you got
                   Catch
                     y = Nothing
                   End Try
               Next
      

     

    HTH,

     

    >L<
    Wednesday, July 25, 2007 2:01 PM
  • Well, I filled a text box with y.Fullname, and the versions displayed are the same as on my pc. Is y.fullname what I'm looking for?

     

    Btw, I notice that in my original mail I never mentioned the file types. The files created are dll - so its

    expression_host_abc12324334435435435.dll

    in the temp folder.

     

    WPF is not installed on the problem pc. There's nothing unusual in the program list. As its a new pc, the list is small so I should easily spot anything out of the ordinary.

    thanks

     

     

    Thursday, July 26, 2007 9:11 AM
  • Another piece of the puzzle. Impersonation is used to load the data for the report.

    The problem PC can load reports where there is no impersonation. No expression host files are generated in that case.

    Something about the impersonation generates the expression host files. But only on this one pc! Sigh.

    Thursday, July 26, 2007 1:52 PM
  • Well, that's pretty cool. Thanks for figuring that out! 

     

    To answer your various messages at once: I'm sorry about WPF being a red herring.  I also don't think you should fixate on those files being generated.  Likely they are generated on *all* the PCs as temporary files but removed on successful completion of some action.  I should have said that before, probably (and don't worry I was pretty sure they were DLLs before you mentioned the filetypes <s>.)

     

    So let's look at how the impersonation is done and what might be involved here.  Does your code look like this http://blogs.msdn.com/bimusings/archive/2005/11/05/489423.aspx or different?  Is the new PC in a different domain or anything?  If you try the code you see in that post, do you see anything different about the before/after values reported for this PC rather than on a different one?

     

    >L<

     

     

     

    Thursday, July 26, 2007 3:23 PM
  • Hi Lisa

    The PC is in the same domain.
    I use very similar Impersonation code, which I store in a class. Typical example code below.
    The main difference would be:
    reportViewer1.ServerReport.ReportServerCredentials.ImpersonationUser = newId

    I'm using a local report, so there seems to be no equivalent. As you can see below, I stop the impersonation once the data is loaded. Is there some way to set credentials for local reports?

     

    '*******************************************
    Dim Imper As New clsImpersonation

    If Imper.Impersonate_User Then
     ' Fill the dataset
     Me.LedgerTableAdapter.Fill(Me.AccountsDataSet.Ledger

     ' Data loaded, stop the impersontation
                   ' NOTE - Not stopping seems to cause problems when the parameters are loaded
                   Imper.Stop_Impersonation()

                   Dim parmRenewals(0) As ReportParameter
                   parmRenewals(0) = New ReportParameter("ReportBranch", stBranch)
                   Me.ReportViewer1.LocalReport.SetParameters(parmRenewals)

                   Me.ReportViewer1.RefreshReport() 

    End If

    Friday, July 27, 2007 3:23 PM
  • Hi there,

     

    (Sorry, I've been away for a couple of days)

     

    I'm afraid this is really not my strong suit. 

     

    Does clsImpersonation do approximately what you see in this post http://blogs.msdn.com/bimusings/archive/2005/11/05/489423.aspx -- or is it different?

     

    Does Imper.Stop_Impersonation() do  what  the WindowsImpersonationContext.Undo() call does in that code? You notice he doesn't stop the impersonation until after the RefreshReport() line. (Yes I know this code is about a ServerReport, and that's why you're asking...)

     

    Can you explain what kind of issues it causes to leave the impersonation in place when you set the parameters?

     

    Do you have any reports that do *not* have parameters?  If so (or if you can try one as a test) does the "problem PC" work with impersonation with such a report?  If not, can you run such a report on the "problem PC" if you change where you're undoing the impersonation to after RefreshReport()?

     

    One other thing: this rang a "faint" bell and I went looking at old threads for why... see here http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1705774&SiteID=1 ... there was something here about the way s/he was installing the reportviewer control that made a difference on only one PC, just like your case. 

     

    >L<

     

     

     

    Wednesday, August 1, 2007 5:03 AM
  • Hi

    I have reports without parameters, and still the same issue.

    I've tried stopping Impersonation before RefreshReport, and after. It doesn't work in either case.

    I did fresh installs, with the report viewer included this time. Still no go.

     

    Here's a sample error message, this time when the parameters are set:

     

     

    Microsoft.Reporting.WinForms.LocalProcessingException: An error occurred during local report processing. ---> Microsoft.Reporting.DefinitionInvalidException: The definition of the report 'Main Report' is invalid. ---> Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: An unexpected error occurred in Report Processing. ---> System.IO.IOException: The process cannot access the file 'C:\Documents and Settings\kathleenlonergan\Local Settings\Temp\expression_host_d2085148d7064e868cb98926c54e851e.dll' because it is being used by another process.
       at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
       at System.IO.File.Delete(String path)
       at Microsoft.ReportingServices.ReportProcessing.ReportCompileTime.InternalCompile(Report report, AppDomain compilationTempAppDomain, Boolean refusePermissions)
       at Microsoft.ReportingServices.ReportProcessing.ReportCompileTime.Compile(Report report, AppDomain compilationTempAppDomain, Boolean refusePermissions)
       at Microsoft.ReportingServices.ReportProcessing.ReportPublishing.Phase3(ParameterInfoCollection& parameters, AppDomain compilationTempAppDomain, Boolean generateExpressionHostWithRefusedPermissions)

     

     

     

     

    Wednesday, August 1, 2007 10:11 AM
  • Look at your error.  Microsoft.ReportingServices.ReportProcessing.ReportPublishing.Phase3(ParameterInfoCollection& parameters, AppDomain compilationTempAppDomain, Boolean generateExpressionHostWithRefusedPermissions).  Why is this happening?

     

    Once again, I am pretty sure that all your PCs have these generated DLLs, unless they are only generated when permissions are refused, but there is really a good change that they are created and normally destroyed properly on *every* impersonation attempt.  Why are permissions being refused on this PC is the point?

     

    >L<

     

    Wednesday, August 1, 2007 3:10 PM
  • I wish I knew!

     

    Yesterday, I installed VB Express on that PC, and those reports work fine from within visual studio. But still the same issue with the runtime reports. And I don't fancy teaching the user how to use visual studio!

     

    Any idea where such permissions might be kept?

     

    Thursday, August 2, 2007 8:19 AM
  • Btw, I never posted the actual error. When the report is launched, I get a message where the report should be:
     
    An error occured during local report processing.
    The definition of the report 'Main Report' is invalid.
    An unexpected error occured in Report Processing.
    The process cannot access the file 'C:\Documents and Settings\kathleenl\Local Settings\Temp\expression_host_d2085148d7064e868cb98926c54e851e.dll' because it is being used by another process.

     

    Thursday, August 2, 2007 9:40 AM
  •  

    You actually did post the error message, in your first post <g>.

     

    >L<

    Thursday, August 2, 2007 2:46 PM
  • Did you read that old thread I pointed you to?

     

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1705774&SiteID=1

     

    Notice that a difference in his installation routine solved the issue for him.  So I am somehow not surprised that it would work through VV Express...

     

    I don't think it's a question of "where the permissions are kept" but "what identity is being used" given the way the reportviewer was originally installed.

     

    In my Visual Studio box, my winforms reportviewer control is here C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\Microsoft.ReportingServices.ReportPreview.dll

     

    Where is yours?  Is there another copy of this DLL anywhere ?  And how did you do your original install of the control, can you un-do that and try it again, maybe witih reference to that old thread?

     

    >L<

     

     

     

    Thursday, August 2, 2007 2:57 PM
  • 1) Installation - I did unintsall and try the way in that thread, made no difference.

     

    2) On the problem pc, I was logged on as that user when I ran reportviewer.exe

     

    3) On my pc, I cannot find any Microsoft.ReportingServices.ReportPreview.dll

    In that folder, the only dll is Microsoft.ReportDesigner.dll - version 8.0.50727.762

     

    Thanks for you help on this, I do appreciate it.

    I don't think there is much more I can do with regards to the install. It is probably some security issue, maybe like http://msdn2.microsoft.com/en-us/library/aa378184.aspx but I can't be sure. When I get time, I'll check all the security settings on the problem pc.

    Friday, August 3, 2007 9:02 AM
  • I'm terribly sorry, I was using Reflector and Microsoft.ReportingServices.ReportPreview.dll is where it told me ReportViewer was (I think an old version). 

     

    But when I look in my project, I see

    C:\Program Files\Microsoft Visual Studio 8\ReportViewer\Microsoft.ReportViewer.WinForms.dll as the reference.

     

    Reflector says  Microsoft.ReportViewer.WinForms.dll

    Version: 3a1e9a50-2a5b-446a-ae77-27026571edb8
    Location: C:\Program Files\Microsoft Visual Studio 8\ReportViewer\Microsoft.ReportViewer.WinForms.dll
    Size:

    339968 Bytes

     

    I assume you have that one? Mine is dated 12/2/2006.  Does yours match?  (sorry to be tedious and thank you for thanking me but I don't think I've been very much help so far!)

     

    I've been thinking about this some more.

     

    The location is :\Documents and Settings\kathleenlonergan\Local Settings\Temp\ .

    Maybe the problem is that the impersonation process generates the file in the temp directory for one user and then doesn't have the permissions to get rid of those files because it's in the persona of  another user

     

    So maybe we're going about this the wrong way.  Maybe we have to figure out a different location for the temp files and tell the app about them.

     

    Does this sound reasonable or promising at all to you?  If so, maybe just try adding the user who you're impersonating with permissions to that directory first, and then see if we can find out how to redirect them later.

     

    >L<

     

     

     

     

     

     

     

    Friday, August 3, 2007 2:25 PM
  • Hi Lisa,

     

    Was Vayze_Dev able to find a solution?  I'm also experiencing a similar issue, so I'm interested in knowing what the solution was (if any).

     

    Thanks!

     

    Stephen 

     

    Saturday, November 17, 2007 1:39 AM
  • For the record we had the same problem and it was related to Anti-virus on the machine. The same problem would occur on the SSRS Report Server preventing us from deploying the report there.

    SSRS would create the temp file

    AV would start scanning the file

    SSRS would try to delete the file

    AV was not done with the file and SSRS would crap out saying that the file could not be deleted

    ...because the problem was essentially related to system resources and multi-threading - i.e. if the AV would happen to finish with the file before the SSRS compiler had decided to delete it, then the deploy or the preview would work, if not (95% of the time for us) it would fail.

    Keep an eye out for AV running on the machine that's trying to host the report (or preview the report if it's your visual studio development machine).

    Cheers,
    CList

    Tuesday, August 25, 2015 6:00 PM