Posts tagged ‘.net’

The solution was offline during its previous session and will remain offline

If your .Net solution gets disconnected from your Team Foundation Server you might get the following message once you load your solution in Visual Studio. “The solution was offline during its previous session and will remain offline.” in the Output window and your solution is kept offline. Which means your local changes are not picked up automatically and you will need to do manual checkouts and checkins into the repository for local files you have changed.

The trick is to manually reset the values in the registry, where else ?
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers\ ( Your TFS server name )

set the values
AutoReconnect = 0
Offline = 0

Next time you open up your solution you will be asked if you want to connect to your Team Foundation Server, yes please.

If that does not work, try this one

Build .Net 3.5 code with Nant, MsBuild on build server without installing VS2008

If you don’t have enough space to install Visual Studio 2008 on your build machine to build .Net 3.5 solution you can do the following. Most likely you will run into the same obstacles as I did, maybe others as well.

First download Windows SDK for Windows Server 2008 and .NET Framework 3.5

When you install you can skip the documentation and samples, it will bring the install down from 2.4GB ! down to about 525MB, not bad.

If you get the following error when you set the framework to Net-3.5 from Nant

System.NullReferenceException: Object reference not set to an instance of an object. at NAnt.Core.FrameworkInfo.get_Version()

You have a certain version of Nant around 0.86 that has old version of the path for the SDK. In your nant.exe.config under net-3.5 look for this section

        hive=“LocalMachine” />

        key=“SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\WinSDKNetFxTools\InstallationFolder”
        failonerror=“false” />

    <property name=“frameworkDirectoryV35” value=“${path::combine(installRoot, ‘v3.5’)}” />
    <fail if=“${not(directory::exists(frameworkDirectoryV35))}”>The Framework directory for .NET 3.5 does not exist.</fail>
    <property name=“referenceV35” value=“${environment::get-folder-path(‘ProgramFiles’)}/Reference Assemblies/Microsoft/Framework/v3.5” />
    <fail if=“${not(directory::exists(referenceV35))}”>The Reference Assemblies directory for .NET 3.5 does not exist.</fail>

change the sdkInstallRoot key v6.0A value to the following
key=”SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.1\WinSDKNetFxTools\InstallationFolder”

If you get the following as well
MY.Web.csproj(364, 11): error MSB4019: The imported project “C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets” was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

No problem, copy the content of your v9.0 directory from your dev box under C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0 to your build server, these are just configuration files.

Then if your using the Microsoft test extensions you might get this one as well
App\DataAccess\CaseDataAccessTest.cs(5, 17): error CS0234: The type or namespace name ‘VisualStudio’ does not exist in the namespace ‘Microsoft’ (are you missing an assembly reference?)

We will simply solve this one by copying the MS test dll’s from the dev machine and install them in the Gac on the build machine.
C:\tmp>gacutil /i Microsoft.VisualStudio.QualityTools.Resource.dll
C:\tmp>gacutil /i Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll

Now you should be good to go and ready to build on the build server without the heavy VS2008 install.

Mono on the Mac

As great as Mono can be allowing you to run .net application under Win, Linux, Mac and more.  There is a gotcha, if you intend to run on the Mac you can not use the Win forms.  As the Win forms have limited functionality on the Mac or just don’t run,  you are also required to install X11 on the Mac for starters.  What you will have to do is to use the Gtk# UI libraries instead as they are by far more mature in Mono on the Mac.  The strange part is that the Win forms work fine on the linux desktop under Mono.

This doesn’t make any sense, does it ?    If you want cross platform UI application that you intend to run under Mono including on the Mac you need to write it that way from the start, use Mono and Gtk# to develop.  That means for you MS VS .net developers you can’t use your favorite VS editor, at least not out of the box.  You have to get something else like MonoDevelop.   You also have to think about it if you have an old application that you want running under Mono on the Mac, you will have to go in and rip out the Win forms and replace them with the Gtk# forms.

As they put it on the Mono website,

There were two previous attempts to implement System.Windows.Forms in Mono. These initial attempts were done on top of other toolkits: first Gtk, then Wine. Each one had its share of problems, causing it to be abandoned.

Read more…

I’m not bashing Mono by any means, I think it’s a great effort and well worth investing some time using Mono.  Even getting involved if your so inclined.  There is just that gotcha about using Win Forms that I wanted to point out to the unaware Win C# developers.

Asp .net ViewState can be evil

My friend was telling me about how evil ViewState can be when dealing with ASP pages. As I’m new to the .net version of ASP pages I went investigating a little further. Taking a look at my sample two posts ago. Sure enough I’m guilty as charged, it turns out that the state of your controls in your ASP pages is automatically put into the ViewState bucket. In other words if you have large controls with a lot of data such as grids or lists your ViewState will include all of that data held by the control. With that said all of the data will travel between your server and the client on all round trips. It is a big waste of bandwidth.

At first I started up Fiddler which allows you to see the real http data transferred. If you do not yet have Fiddler in your toolbox you should check it out, it’s a great tool. However it doesn’t allow you to examine the ViewState in detail as the tool is more generic.

I did the google and came up on another tool, ViewState Helper Viewer it does exactly what I needed. It shows you the size of your ViewState and further you can drill down on it with a double click which will break the ViewState down into the variables that it’s holding, good job by the author Jon Tackabury. Jon has actually a couple of other impressive tools. As I’m writing this I realize that Jon already wrote ViewState plugin for Fiddler, which is great, I have to check that out.

So let’s take a closer look at the webpage, as seen in the viewer

As you can see at first on the highlighted row, the size of the ViewState is substantial. It is about 31% of the whole page, 15K of worthless data traveling to and from the client on each roundtrip, not good. In order to cut down on the size, simply add an attribute to your control in the html code, EnableViewState=”false”. This will instruct ASP .net not to include the state / data of the control in the ViewState bucket. As I applied that to the grid control you can see the next line above shows much better results than before. Then I further applied it to other controls on the page and now we are down to 456 bytes from 15,184.

If you want to read in depth analyzes of the ViewState and how it works in .net you might want to wander over here. For most pages you might just have to set the EnableViewState attribute on your controls, but for more advanced cases you might have to drill down further.

Sean thanks for being the devils advocate.