Home Dashboard Directory Help
Search

Rdlc files are build into Resources during publish (This is a marker file) by a.pasilis


Status: 

Closed
 as Won't Fix Help for as Won't Fix


1
0
Sign in
to vote
Type: Bug
ID: 468068
Opened: 6/18/2009 12:08:33 AM
Access Restriction: Public
1
Workaround(s)
view
0
User(s) can reproduce this bug

Description

Hello, I'm reporting this bug for the 2'nd time. This bugs goes from VS 2005 and still exists in VS 2008 and if not corrected will exist in VS 2010.
References: FeedbackID=105162 and FeedbackID=431006.
-------- THE PROBLEM ---------------
When i'm publishing a web site that has any *.rdlc files and in "Publish Web Site" dialog i UN-CHECK "Allow this precompiled site to be updatable" checkbox, all *.rdlc files are build into resource and original file content is replaced with message "This is a marker file generated by the precompilation tool, and should not be deleted!".

When a web site is published that way, none of the *.rdlc files can be opened by Microsoft Report Viewer control as it doesn't support the precompilation behavior.

The only workaround now is to replace the published *.rdlc files with original ones from development environment. And this workaround gets realy ugly if website has complex folder structure and a lot of *.rdlc files.
Details
Sign in to post a comment.
Posted by a.pasilis on 12/17/2009 at 3:33 PM
Thank you very much for you efforts and link to the "Deploying RDLC files in local mode for ASP.NET applications" blog. It made my life much easier.

5*
Posted by Microsoft on 12/4/2009 at 3:00 PM
Thank you for your feedback.

We have tried to fixed the issue and have found into significant technical challenges during the attempt. As a result, we are resolving the issue as "Won't Fix". We do want to share the technical details on why we cannot fix this as well as the workaround.

This is specific to Websites. WebApps are just fine (this is usually the case, unfortunately).

ASP.NET has the notion of a BuildProvider, a provider is what compiles some arbitrary resource into C# code, so that it can then be compiled into an assembly and be the basis for an ASP.NET application. For example, a BuildProvider compiles .aspx pages into C#.

Websites are not precompiled. However, you can tell VS to compile your website project just like any other project. What does this do? It just invokes all the defined BuildProviders and makes sure they all compile without error. BuildProviders are defined in web.config. The result of these compilations are thrown away. This is where we stepped in and took advantage of this. RDLBuildProvider compiles the RDLC files in a website to validate them. That is all we want our BuildProvider to do, but BuildProviders are meant to do more, and we inadvertently signed up for more than we bargained for.

The problem is that you can tell VS to precompile your website when you publish it. To do this, VS asks each defined BuildProvider to compile, except this time it keeps the results. The results of the compilation become the assembly that is the website in compiled form. Along with this assembly the .aspx pages and everything else are also kept around. If they change, then ASP.NET will notice this and recompile the site and update the assembly.

When publishing a website, you can tell VS to *not* allow websites to change by unchecking “Allow this precompiled site to be updatable”. That means the BuildProviders will do their thing, the assembly gets created, and then the sources for the BuildProviders (aspx pages, ascx pages, etc) are wiped out, forcing the website to be static and never changing. This is what causes our problem.

Since we have a BuildProvider, VS thinks we should participate in this. It tells us to compile our RDLC, thinking we are going to churn out C# that represents it, and it will get compiled into the assembly. We don’t do that at all, and there is just no way we could without massively changing the viewer. If the user chose to not allow the site to be changed, then VS will wipe out all the RDLC files, assuming they’ve been added to the assembly.


The customer who is very angry over this thinks we should be able to tell the publish tool (which is aspnet_compiler.exe) to just leave RDLCs alone just like it leaves .css and .js files alone. But that’s now how it is designed. It sees RDLCs have a BuildProvider defined for them, and thus assumes they should not be left alone. .css, .js, .html, etc, do not have BuildProviders.


The workaround
Customers can keep our BuildProvider defined and use it while developing the site to validate their RDLCs. When they are satisfied with everything and are ready to deploy a website that they want to not be updatable, then they just have to undefined RDLBuildProvider. To do that, they just have to remove it from web.config before publishing.

Thank you again for your feedback.

Stella Chan
SQL Server Reporting Services
Posted by Microsoft on 12/4/2009 at 3:00 PM
Thank you for your feedback.

We have tried to fixed the issue and have found into significant technical challenges during the attempt. As a result, we are resolving the issue as "Won't Fix". We do want to share the technical details on why we cannot fix this as well as the workaround.

This is specific to Websites. WebApps are just fine (this is usually the case, unfortunately).

ASP.NET has the notion of a BuildProvider, a provider is what compiles some arbitrary resource into C# code, so that it can then be compiled into an assembly and be the basis for an ASP.NET application. For example, a BuildProvider compiles .aspx pages into C#.

Websites are not precompiled. However, you can tell VS to compile your website project just like any other project. What does this do? It just invokes all the defined BuildProviders and makes sure they all compile without error. BuildProviders are defined in web.config. The result of these compilations are thrown away. This is where we stepped in and took advantage of this. RDLBuildProvider compiles the RDLC files in a website to validate them. That is all we want our BuildProvider to do, but BuildProviders are meant to do more, and we inadvertently signed up for more than we bargained for.

The problem is that you can tell VS to precompile your website when you publish it. To do this, VS asks each defined BuildProvider to compile, except this time it keeps the results. The results of the compilation become the assembly that is the website in compiled form. Along with this assembly the .aspx pages and everything else are also kept around. If they change, then ASP.NET will notice this and recompile the site and update the assembly.

When publishing a website, you can tell VS to *not* allow websites to change by unchecking “Allow this precompiled site to be updatable”. That means the BuildProviders will do their thing, the assembly gets created, and then the sources for the BuildProviders (aspx pages, ascx pages, etc) are wiped out, forcing the website to be static and never changing. This is what causes our problem.

Since we have a BuildProvider, VS thinks we should participate in this. It tells us to compile our RDLC, thinking we are going to churn out C# that represents it, and it will get compiled into the assembly. We don’t do that at all, and there is just no way we could without massively changing the viewer. If the user chose to not allow the site to be changed, then VS will wipe out all the RDLC files, assuming they’ve been added to the assembly.


The customer who is very angry over this thinks we should be able to tell the publish tool (which is aspnet_compiler.exe) to just leave RDLCs alone just like it leaves .css and .js files alone. But that’s now how it is designed. It sees RDLCs have a BuildProvider defined for them, and thus assumes they should not be left alone. .css, .js, .html, etc, do not have BuildProviders.


The workaround
Customers can keep our BuildProvider defined and use it while developing the site to validate their RDLCs. When they are satisfied with everything and are ready to deploy a website that they want to not be updatable, then they just have to undefined RDLBuildProvider. To do that, they just have to remove it from web.config before publishing.

Thank you again for your feedback.

Stella Chan
SQL Server Reporting Services
Posted by Microsoft on 6/26/2009 at 7:27 AM
Thank you for your feedback. We are currently investigating this issue.

A possible workaround is to remove the RdlBuildProvider entry from the <system.web>/<compilation>/<buildProviders> section in the application web.config. Please see following: http://weblogs.asp.net/stephensonger/archive/2008/09/10/deploying-rdlc-files-in-local-mode-for-asp-net-applications.aspx
Posted by Microsoft on 6/19/2009 at 1:06 AM
Thanks for your feedback. We are routing this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Posted by a.pasilis on 6/18/2009 at 12:17 AM
Also my and other MS professional's posts from FeedbackID=105162;
Posting this just to let you know that this issue is realy IMPORTANT and that you should start working on it or say that you cannot solve this bug.
- Quote -
For God's sake pplz at Microsoft. I'm fed up with all the bugs you produce and incompetence to solve them. The very line in the issue saying "This is a marker file generated by the precompilation tool, and should not be deleted!" means that he published the site with "Allow this precompiled site to be updatable" option checked off. The problem is that publish tool erroneously compiles *.rdlc files into resources and this behavior is not supported by Microsoft Report Viewer.
Same behavior reoccurs in Visual Studio 2008 if one is trying to use same publish options.

This issue has been reported in 2006. I'm writing this post in 2009 and I still have same problem. So please stop outsourcing your product support to India, or start addressing these issues.

Thank You
Posted by a.pasilis on 2009.04.07 at 00:20
-
I agree with a.pasilis. I have been struggling with this issue since 2005. As a certified MS professional, I am hurt by the corporate ignorance exposed on this page. Posted by Dimitri S on 2009.04.09 at 10:54
- end of Quote --
Posted by a.pasilis on 6/18/2009 at 12:14 AM
One thing that i would like to Emphasize. For my previous Feedback you closed it with answer
- Quote -
Thank you for the bug report. In order to make the .rdlc files editable you will need to check the "Allow this precompiled site to be updatable" checkbox. Unchecking this is what is causing your files to be non-updatable.

Hope this helps...
Web Tools Team
- end of Quote -

What I don't understand is if you can understand ENGLISH LANGUAGE or not. I didn't want to make my *.rdlc files to be editable. That was not even stated as a problem so I don't understand how you could come up with such answer. I want to compile my web site with "Allow this precompiled site to be updatable" UNCHECKED and still be able to view my reports. Don't know how to explain this more clearly.
Sign in to post a workaround.
Posted by a.pasilis on 12/17/2009 at 3:31 PM
Thank you for your reply. It was very helpfull and the workaround solved my problem. By default when you add a Microsoft report viewer to your website, visual studio adds a rdlc build provider to web.config file.

<buildProviders>
<add extension=".rdlc" type="Microsoft.Reporting.RdlBuildProvider, Microsoft.ReportViewer.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</buildProviders>

So the wourkaround would be to remove the <add> tag that contains .rdlc as extension or just add another tag right after the <add> tag:

<remove extension=".rdlc" />

I prefer to add a <remove> tag because if i just delete the add tag, whenever i drop another report viewer control into one of the pages, the tag will be back, and it's easy to forget to remove it before build. And adding the remove tag for .rdlc extension doesn't require additional checking of web.config buildProviders check