Disclaimer: This worked for me, but as with all undocumented hacks, proceed at your own risk.
There may be a better way to do this, but I couldn’t find it. I trust that your
.rdlc files are in source control, and that you can rollback to a previously working version if this causes problems.
For various reasons, I needed to upgrade my RDLC report’s schema version from the default 2008 version to the 2010 version.
When you create a basic, empty RDLC report in Visual Studio 2013, here’s what the namespace declaration looks like:
To coerce Visual Studio 2013 into upgrading the report’s schema to the 2010 version, do the following to your report:
- Open the Toolbox
Indicator onto your report
Save your report
Delete the newly-added
Indicator from your report
Save your report
Or, in animated gif form:
When you’re done, the report’s namespace declaration should look like this:
Hope this helps.
If you don’t know about the File Nesting extension from Visual Studio, watch the demo video on Channel9. It’s a very nice productivity tool.
After installing the File Nesting extension in Visual Studio 2013 Ultimate, right-clicking and nesting individual files worked, but right-clicking on, e.g., the Scripts folder and selecting
File Nesting ->
Auto-nest selected items did nothing.
Flummoxed, I had a peek in
Options, and lo and behold, there is a settings page for
File Nesting. By default, all of the rules were disabled. Once I tweaked the options, auto-nesting started working as expected.
Setting these options to true made auto-nest work for me.
Just a little tip that will hopefully save you some headaches.
If you’re getting this error when trying to debug an ASP.NET Web application on IIS7 or greater, check the system.webServer element in your Web.config. If you have the httpErrors element configured, you won’t be able to debug. For your local dev environment, remove or comment out the httpErrors element, and you should be good to go.
From my ASP.NET 1.1 days, I have a hazy memory of Visual Studio’s debugging startup process requesting a bogus URL on the target Web site, and then doing something with the 404 response prior to launching the debugging session. Obviously, if it’s expecting a 404 or the page to contain certain text, redirecting to an error page will prevent you from launching the debugger successfully.
If you happen to know specifically why this happens, please leave a comment (or contact me if comments are closed), and I will gladly update this entry.
In Visual Studio 2008, when you add a new Web form to your project, the "using" section of the code-behind contains a lot noise:
You may very well need some of those namespace declarations, but odds are high that you don't need them all. But which ones can you remove without breaking your page?
Visual Studio has a nice feature called Organize Usings, which you access by right-clicking anywhere in the code-behind page. The menu looks like this:
When you click on "Remove and Sort", it removes any unused "using"s and sorts those that remain.
So now, instead of the mess that we had before, we have a much cleaner "using" section in our source code file:
Pretty slick, huh?