error – 700cb Programming

Visual Studio 2015 + Silverlight In VB.NET

Posted on September 10, 2015 by anachostic

At work, I was the first to upgrade my machine to Windows 10 and Visual Studio 2015. Opening our application’s solution, I started resolving little errors here and there. One problem was not so simple and had a very obscure solution.

We have a small collection of Silverlight apps written in VB.NET. With the upgrade to Visual Studio 2015, they would not compile. The errors returned were:

vbc : error BC30002: Type ‘Global.Microsoft.VisualBasic.ApplicationServices.ApplicationBase’ is not defined.
vbc : error BC30002: Type ‘Global.Microsoft.VisualBasic.Devices.Computer’ is not defined.
vbc : error BC30002: Type ‘Global.Microsoft.VisualBasic.MyServices.Internal.ContextValue’ is not defined.
vbc : error BC30002: Type ‘Global.Microsoft.VisualBasic.ApplicationServices.User’ is not defined.
vbc : error BC30002: Type ‘Global.System.ComponentModel.Design.HelpKeyword’ is not defined.

In the course of troubleshooting, I excluded everything from the project except the AssemblyInfo file and I still got the errors. So I created a new Silverlight project, which built fine, and compared the Detailed compiler output. The compiler line in the 2015-created project had a slightly different parameter (difference highlighted):

/define:"CONFIG=\"Debug\",DEBUG=-1,TRACE=-1,_MyType=\"Empty\",PLATFORM=\"AnyCPU\",SILVERLIGHT=1"

This clicked with me from my experience with building Silverlight apps for the Zune, where you had to exclude the My namespace that is created with VB.NET applications. Look at the assemblies being referenced. ApplicationServices.ApplicationBase (My.Application), Devices.Computer (My.Computer), ApplicationServices.User (My.User).

So, how do you get this extra compile setting? It’s in the .vbproj – there’s no UI for it. You’ll have to edit the vbproj file directly.

Unload the Silverlight project, right-click it, and choose Edit .vbproj. Look for the node <NoStdLib>true</NoStdLib> (there will be one per project configuration) and after it, add: <MyType>Empty</MyType>. This node is included with new Silverlight projects in VS2015.

Save and reload the project and the MyType flag will be included in the vbc command line, which will allow the Silverlight application to compile.

Of course, a lot of people will probably create a new Silverlight project and move all their code into it and be just as successful. But, if you don’t want that hassle, or if you just want to know why (as I did), there’s the solution.

SSRS ReportViewer NullReferenceException on Dispose

Posted on March 13, 2015 by anachostic

I recently assisted on troubleshooting an error in a utility application where an exception was being thrown on the dispose of a Microsoft.Reporting.WebForms.ReportViewer. The environmental conditions were pretty specific, so it’s possible you’d never see something like this in your environment. But if you do, here’s how you can work around it.

The specific condition is that we have a shared library of code for both desktop and web applications. One of the functions in that library takes some parameters for an SSRS report and returns a byte array for a rendered PDF of the report. Because the library initially was used exclusively by the website, the WebForms version of the ReportViewer was used. As time went on, the library was used by desktop apps and windows services. That’s when the trouble began.

So, if you are using a WebForms.ReportViewer in a desktop application, you may get this exception when disposing the instance. Digging into the decompiled code for the ReportViewer control suggested it was because there was no HttpContext available. For us, the long-term fix was clear: use the WinForms version of the ReportViewer. In the short term though, adding this line of code resolved the error:

If HttpContext.Current Is Nothing Then HttpContext.Current = New HttpContext(New HttpRequest(IO.Path.GetRandomFileName, "http://www.google.com", ""), New HttpResponse(IO.TextWriter.Null))

This created an HttpContext where there was none before, and the ReportViewer instance was able to be disposed without an error.

We Have A Problem

Posted on November 15, 2010 by anachostic

It’s always fun to see an error message you’ve never seen before – even after using a product for almost 10 years. While trying to check the value of an object while sitting at a breakpoint:

Cannot evaluate expression because we are stopped in a place where garbage collection is impossible, possibly because the code of the current method may be optimized.

Microsoft has very strict guidelines about the verbiage used in their programs. I can’t believe they let an error message pass through using the word “we” in it. It’s good to know that the .NET compiler feels that we’re all in this together. Additionally, the use of the word “impossible” and the vagueness of “possibly because” and “may be” are very out of place.

I’ve never seen an error message so clearly state “That absolutely cannot be done. I know why, but I don’t know why.”