Linq causes the Setup project to fail when building

All of a sudden, my setup project stopped building. It was very strange - when I tried to build it, it would say that the build failed, but it gave no errors. Nothing anywhere.

Thankfully, I'm not the first person to have run across this. It turns out that adding Linq to one of the projects in my solution caused this failure - it appears to be a bug in Visual Studio.

The solution appears at Microsoft's Connect site (be sure to look in the 'Workarounds' tab) - https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=317870

Here is what Daren wrote:

1. Close VS 2008.
2. Open the project file containing the LINQ To SQL item in Notepad.
3. Remove the following lines:
<ItemGroup>
<Service Include="{3259AA49-8AA1-44D3-9025-A0B520596A8C}" />
</ItemGroup>

The Setup Project will now build successfully. However, if you double-click the DBML file to open the designer in VS 2008 the Setup Project will stop building again. The above lines do *not* get re-added to the project file but the Setup Project will stop building anyway. Just restart VS 2008 and it will work again -- until you open the DBML designer again. Once the Setup Project fails due to this problem it will never build successfully until after you restart VS 2008.

OOO, C#, and C/AL

I've been working with building some web services built on the Microsoft Dynamics Nav 2009 web services platform. Microsoft is doing something fairly slick here - you write code in the C/AL language, save it as a Nav Object, expose it as a web service, and the web services layer automatically translates the C/AL to C# and runs it in .Net. This allows you to debug the code using visual studio, among other things.

But it's not perfect. Sometimes it makes mistakes.

I had this line of code in C/AL

IF AVSetup."Sub Award Dimension No." - 1 IN [1..8] THEN BEGIN

Which auto-translated to this in C#:

if(aVSetup.Target.

GetFieldValueSafe(90, NavType.Integer).ToInt32()-(1 >= 1 && 1 <= 8))

Oops. The order of operations got mixed up. The C/AL code subtracts one, then sees if the value is between 1 and 8. The C# sees if 1 is between 1 and 8 (getting a boolean value) and then tries to subtract the boolean value from the number. C# then gives this error:

Operator '-' cannot be applied to operands of type 'int' and 'bool'

Thankfully, the solution for this is simple. All you have to do is use extra parentheses to explicitly set the Order of Operations.

IF ((AVSetup."Sub Award Dimension No." - 1) IN [1..8]) THEN BEGIN

SQL Reporting Services, Sharepoint, and Firefox

I ran into a problem when I tried to use Firefox to view a SQL report on Sharepoint. In IE it works fine, but when it hits firefox, a 'display: block-inline' CSS style set on a table buried way down in the code caused firefox to do this:


The report is squeezed into a little IFrame, and you don't even get a vertical scrollbar. Sure, you can right-click on it and get your browser to show that IFrame as the main page, but that's not a good solution for end users. So I set about trying to figure out how to take care of this.

I found all kinds of helpful information about the problem. Lots of people had solutions, but none of them worked for me. Here is some of what I found:

• Adam Tuliper - Fixing SQL Reporting Services for Firefox
• ASP.Net Forums - Mozilla alignment problem with reports

Part of the problem is that I'm using SQL Reports with Sharepoint in Sharepoint Integration mode, whereas they seem to be using standable SQL Reports.

So I started digging. I used Firebug, a great tool by the way, to dig around the DOM to find out what was causing the problem. After drilling down through countless nested tables, I discovered that there was one control in particular that was causing the trouble:

<table id="m_sqlRsWebPart_ctl06_ctl13" cellspacing="0" cellpadding="0" style="overflow: auto; display: inline-block; width: 100%; height: 100%;">

In particular, the 'display:inline-block' didn't get along so well with firefox. When I removed that with Firebug, the report showed up just great. But the problem is that this HTML code is actually assigned by Microsoft.ReportingServices.Sharepoint.UI.WebParts.DLL (or by something that it calls), and modifying the DLLs isn't really an option.

After searching around, I found out that you can have a CSS declaration in a stylesheet override an element CSS declaration. These guys clued me in to this gem:

• Craig Bucker - How to Override Inline CSS Styles
• Chris Coyier - Override Inline Styles with CSS

So I went to the reports server and went into the 12 hive at 12\TEMPLATE\LAYOUTS\ReportServer\RSViewerPage.aspx, and inside the HEAD element I added this:

<STYLE type="text/css">
table#m_sqlRsWebPart_ctl06_ctl13[style] {
display: table !important;
}
</STYLE>

Et Voila, it works! This chunk of CSS overrides what the DLL puts on the table element and changes the display property from inline-block to table. That then causes Firefox to behave properly and show the report.

Well, mostly. The other thing you need to do is open your report designer, open the report, and create a blank textbox that spans the width of the report. That will make sure that nothing on the right side of the report gets cut off.