Archive

Archive for the ‘Visual Studio 2005’ Category

A Flexible “Is In Range” Extension Method

I’m working out some business rules for an application that allows the end user to specify whether or not to direct records by the first letter of the last name of a student or by the grade of the student.

The quick extension method looks like this:

public static bool IsInRange<T>(this T value, T start, T end)

where T: IComparable<T>

{

return value.CompareTo(start) >= 0 && value.CompareTo(end) <= 0;

}

Our tests:

[Fact]

public void IsInRange_returns_correct_boolean_for_comparison()

{

9.IsInRange(1, 10).ShouldBeTrue();

“L”.IsInRange(“A”, “J”).ShouldBeFalse();

“A”.IsInRange(“A”, “A”).ShouldBeTrue();

“B”.IsInRange(“A”, “A”).ShouldBeFalse();

12302.IsInRange(1, 10).ShouldBeFalse();

 

“Bob”.IsInRange(“A”, “A”).ShouldBeFalse();

“Smith”.IsInRange(“A”, “Z”).ShouldBeTrue();

}

Everything works well… I haven’t tested all of the permutations and types yet… but it gets me out of the jam I’m in right now.

Is there a better way? 😀

Auto Incrementing Visual Studio Project Versions

March 9, 2009 Comments off

I’m not using NAnt or anything fancy for most of my projects—so I needed a simple, MSBuild way to automate my version numbers in a project..

<tangent>
HOLY CRAP! Why isn’t this built into Visual Studio Pro?
</tangent>

Here we go:

1. Download the latest build of AssemblyInfoTask (download here) (was 1.0.51130.0 for me).  This is a semi-Microsoft supported MSBuild task that gives you a lot of flexibility over your AssemblyInfo.cs files.

2. Install AssemblyInfoTask.  When prompted where—install into the GAC.  If you don’t have access to the GAC on your workstation, then why aren’t you developing on a VM? 😉

3. Locate the Microsoft.VersionNumber.targets file.  If you installed to the GAC, it should be at %ProgramFiles(x86)%\MSBuild\Microsoft\AssemblyInfoTask Or %ProgramFiles%\MSBuild\Microsoft\AssemblyInfoTask (depending on your architecture).

4. Copy the Microsoft.VersionNumber.targets file into a location in your solution or project.  I recommend $(SolutionDir) so you can share it amongst all of your projects.  The guilde recommend pointing to the file directly; however, you can’t modify the base Major versions that way (without setting the same major version for ALL projects you ever work on).  You can also rename it as approprate.

“Int16s Are Too Small” Or “Why 2007 Broke Versioning” Fix

According to experts who are much smarter than me, the build version numbers are Int16s—meaning 65535 caps out the number.  Unfortunately, the year 2007 breaks this (070101 or 70101 for 07 jan 01) doesn’t fit within an Int16.  Stellar.

The MSBuild team recommended taking out the year and simply placing a 1 infront of it.  That works; however, I really like having the year in there somewhere.

For me, I’ve placed the year into the MinorVersion.  After reviewing most of our practices, the minor version for most of our projects changes with annual maintenance OR not at all (we bump the major version).  This, if nothing else, will help standardize when it changes. 🙂  As always, YMMV.

No matter which solution you choose, you’ll need to remove the year from the BuildNumberFormats.

In your Targets file, you can change the two lines to report out the MMdd (0309, for example, today) to work around the bug.  I’ve bolded the two lines below.  As you can see, I also added the “9” to the MinorVersion to represent 2009. 

<PropertyGroup>

  <AssemblyMajorVersion>3</AssemblyMajorVersion>

  <AssemblyMinorVersion>9</AssemblyMinorVersion>

  <AssemblyBuildNumber></AssemblyBuildNumber>

  <AssemblyRevision></AssemblyRevision>

  <AssemblyBuildNumberType>DateString</AssemblyBuildNumberType>

  <AssemblyBuildNumberFormat>MMdd</AssemblyBuildNumberFormat>

  <AssemblyRevisionType>AutoIncrement</AssemblyRevisionType>

  <AssemblyRevisionFormat>00</AssemblyRevisionFormat>

</PropertyGroup>

 

<!– Properties for controlling the Assembly File Version –>

<PropertyGroup>

  <AssemblyFileMajorVersion>3</AssemblyFileMajorVersion>

  <AssemblyFileMinorVersion>9</AssemblyFileMinorVersion>

  <AssemblyFileBuildNumber></AssemblyFileBuildNumber>

  <AssemblyFileRevision></AssemblyFileRevision>

  <AssemblyFileBuildNumberType>DateString</AssemblyFileBuildNumberType>

  <AssemblyFileBuildNumberFormat>MMdd</AssemblyFileBuildNumberFormat>

  <AssemblyFileRevisionType>AutoIncrement</AssemblyFileRevisionType>

  <AssemblyFileRevisionFormat>00</AssemblyFileRevisionFormat>

</PropertyGroup>

 

This results in a version string that looks like 3.9.0309.{increment}.

5. Open up your project’s solution and unload the project you are wanting to auto-increment. Towards the end of the file, you’ll see the default MSBuild C# build path; add the location to your new .targets file in your solution directory.

<Import Project=$(SolutionDir)MyProject.VersionNumber.targets />

7. Save and Close and Reload the project.

8. Build/Rebuild your project and the AssemblyInfo.cs should set to the specified increment scheme.

You’re done!

“Too Many WebResources?” Fix 

My project references numerous resources for images and style sheets; however, having these inside of AssemblyInfo.cs seems to cause it to go haywire and throw array errors (assumingly because there is more than one [assembly:WebResource()] call).

To fix this, I moved my WebResources out of AssemblyInfo.cs and into a new file under Properties called WebResources (Add New Item > Assembly Information File).  Strip out everything except the WebResources you copy in and the project now compiles like a champ.

For additional setup details and options within the .targets files, the AssemblyInfoTask installer comes with a CHM help file that covers additional customizations available.

HTML Formatting and Spacing in ActiveReports

March 6, 2009 1 comment

ActiveReport’s RichTextBox is great for presenting HTML-styled content on PDF reports; however, there seems to be a snag with a few of the HTML tags and how the RichTextBox translates the commands to HTML.

To print out a bit of HTML (from a field), I have the following StringBuilder my details_Format:

builder

       .AppendFormat(

       @”{0}On {1}, <strong>{2}</strong> wrote: <br/>{3}<br/><br/>{4}”,

       […]);

However, the <strong> tags are not properly rendering spaces between them:

Issues with Spacing

There seems to be an existing notice on the DataDynamics forums (here) regarding the spacing, but it’s from 2007–-I’d assume it’s been fixed by now; however, I can’t find it in any of the AR3.0 release notes.

So what’s the fix?

Force the spaces in with non-breaking space commands.

       @”{0}On {1},&nbsp;<strong>{2}</strong>&nbsp;wrote: <br/>{3}<br/><br/>{4}”,

Bingo!

Fix With Spacing

Setting the ViewPort for iPhone/iTouch Ready Web Sites

January 13, 2009 Comments off

Scenario:

After rolling out two new web applications targeted for WindowsMobile and Blackberries, we had a request to test and support Apple iPhone/iTouch devices.  Not a big deal, or so I thought.

Unfortunately, Safari on these devices displayed properly, but every page required zooming and was almost impossible to read.  There had to be a way to get Safari to respect the set width of the page rather than scale it out.

Solution:

Michael: “are you setting the viewport?”

Thanks to Google and a bit of help from a friend (thanks Michael!), the mysterious solution was just a meta tag away.  The best place to start would be the “Safari Web Content Guide for iPhone OS”.  I had found bits of this document elsewhere, but the information about the Viewport tags are extremely helpful.

The default viewport width is 980px; however, you can hard code the width of your page.  I placed the following tag in the <head> section of my MasterPage for the mobile site.

<!– meta tag for iPhone/iTouch devices –>

<meta name=”viewport” content=”width=350px” />

That worked; however, the HTML elements (buttons, selects, etc) were still far too small.  It seems that “fit to device” is more explicitly expressed with the device-width value.

<!– meta tag for iPhone/iTouch devices –>

<meta name=”viewport” content=”width=device-width” />

device-width not only fit the text to the screen, but also properly scaled the elements as well.

Excellent. 🙂

I need to fully read that Safari Web Content Guide to see if there are other wonky tags for iDevice goodness. 😉

Review: ANTS Profiler 4.0 Beta

August 11, 2008 2 comments

A few months ago, I purchased ANTS Profiler 3.2 and have loved it.  It’s really helped me dig into some of my code, find performance hang-ups, and (I think) turn out better code and learn (it’s sometimes hard to find “do betters” in a single dev environment).

I played around with a few of the 4.0 builds and they were nice, but I honestly didn’t have time to dig into them.After a busy weekend, I sat down and spent some quality time with the 4.0 beta (b 4.0.0.740) of ANTS Profiler and am blown away.

Installation

Installation was a breeze.  The 4.0 installer saw my existing 3.2 install and “upgraded” it; however, I was a bit surprised to find that the 3.2 sat side-by-side with 4.0.  That’s PERFECT, actually, and I hope they plan to keep it that way.

ANTS 4.0 -- Installed!

First Run Through 4.0

I’d like to start off by saying the new profiler startup UI is fantastic.  The prior “multi-step” wizard was great and easy to work through; however, I really like seeing everything on the first page.  Simply set the options and click Start. 

Profiler Settings - click for full image
(click for full image)

In addition, the quick access to additional performance counters, such as page requests and memory usage is really helpful.  I’m curious if additional performance counters can be added or if the list (see below) is the only ones handled by ANTS. 

Once things are rolling, the results come pouring in.  Just like with 3.2, 4.0 has detailed line level data—percentages per called line, hits, etc.  Very useful information.

However, the new call trees are sweet!  Why look at spreadsheets and lines when a graphical representation is available?  I have to find ways to boggle coworkers with these. 🙂

My understanding is (I haven’t RTFM’d yet) is that the call trees display both your code (those that are bolded) and the managed code from .NET and called libraries (those that are tinted).

From here, I can see that a good deal of my slow down querying AD is coming not from the top level code, but from the Ldap code in System.DirectoryServices.Protocols and that the wait caused by that is the biggest hold up in all of Session_Start.

Another cool feature is the live performance counter view while you’re profiling.  This perfmon look into your application’s performance allows you to pause and checkout spikes (or unexpected dips) in any of the locked counters.

Counters graph.

To see the line-by-line details, simply drag the mouse along a section of the graph to select it.  ANTS will zoom in on just that area.  You can see the “highlighted” area below in blue.

Line Graphs, Zoomed In

That spike can be diagnosed in the line view—one of our methods is that doesn’t call very often (42 times) is taking a HUGE amount of time due to another that is calling 1000+ times.  Time to drill into that code and find a way to unloop it.

Conclusion

ANTS 4.0 seems quite a bit faster than 3.2 profiling the couple of .NET 3.5 web projects that I had sitting around in development.  In the past, I tended to avoid running ANTS against local Cassini projects; however, this kept up pretty well (though I think it does explain the LdapConnection latency).

It also appears that 4.0 can profile remote IIS instances (at least it doesn’t refuse it like 3.2 does); however, I haven’t quite gotten that working with the port settings (more to learn).

I haven’t hit all of the features yet, but I’m very impressed with the new look and feel, added “while you profile” live features, and the call trees. I can’t wait for the next beta and/or gold release—it’s looking good!

Resharper 4.0.1 Beta Released

August 4, 2008 Comments off

Since the 4.0 release, the JetBrains team has been working diligently towards the 4.0.1 release.  According to Confluence, there are several hundred bug fixes between 4.0 diamond and the current build (#917) of 4.0.1.

What’s new with 4.0.1?  According to a newsgroup post from Ilya, the 4.0.1 updates revolve around bugfixes; I haven’t found any indication of additional features.  I haven’t scanned through all of the JIRA cases yet, but there’s a huge volume of “fixes”—which surprises me.  R# 4.0 has been running like a dream for me.

I’m installing 4.0.1 beta (marked “works here”) now; the joys of testing!

IQueryable Methods on ActiveReports ControlCollections

I’m currently working on a project with an extremely complex, multi-page report.  Unfortunately, a customer requirement was EXACT typography to the “Excel” report and there are hundreds (literally) of data points randomly on the page. 

There isn’t a good way to iterate through the results (it’s a very detailed grade card for elementary students) and still match the layout requirements.

So, I went about “drawing” it out—lots of Label controls, lines, boxes, and such.  To save myself a bit of time assigning DataFields, querying results, etc., I opted for a different kind of iteration—control iteration.

My schema was simple: q#i#, for the quarter and the primary data point of the report, the indicator Id.  Since my business object, a Report, was already assigned to the ActiveReport document, I could simply iterate away!

Unfortunately, if you try to determine if the detail.Controls (a ControlCollection) contains a control and it doesn’t exist—it doesn’t simply return null, it throws an exception.  In addition, the ControlCollection doesn’t have an Exists or a FindControl method.  So, you’re stuck catching exceptions.

foreach (var indicator in _indicators)

{

try

{

var indicatorHeader =

string.Format(“i{0}”, indicator.Id);

((Label)detail.Controls[indicatorHeader]).Text =

IsSpanish                                                                           

? indicator.SpanishText                                                                          : indicator.EnglishText;

}

catch (Exception)

{

continue;

}

}

Unfortunately, that destroys performance—especially with hundreds of iterations (of indicators).

There’s a way around this, at least in my opinion.  Instead of addressing the controls as part of the details.Controls ControlCollection, use a custom IQueryable collection.

Begin by adding a private variable to the report to hold the controls.  In my case, all of the controls I’ll be modifying are Label (of ARControl) controls.

private IQueryable<Label> _controls;

On my ReportStart (I’m sure I could use another method, but since these are static controls, that seemed a good place to start), dump all Label controls into a generic List object (because you cannot add into an IQueryable).

var controlList = new List<Label>();

foreach (var control in detail.Controls.OfType<Label>())

{

controlList.Add(control);

}

_controls = controlList.AsQueryable();

OR, if you want to get fancy and save a few objects:

_controls = detail.Controls.OfType<Label>().AsQueryable();

At this point, your _controls object has all of the standard LINQ goodness.  Our foreach now looks like:

foreach (var indicator in _indicators)

{

var indicatorHeader =

string.Format(“i{0}”, indicator.Id);

var indicatorControl =

_controls.SingleOrDefault(x => x.Name == indicatorHeader);

if (indicatorControl != null)

       {

              indicatorControl.Text = IsSpanish

? indicator.SpanishText

: indicator.EnglishText;

}

}

The entire block can be wrapped in a try/catch—rather than each “object check”.  The report also runs almost 100x faster.