Category Archives: .Net

Rocky Lhota at CNUG

Posted on by

I was able to get to the CNUG meeting where Rocky Lhotka was the feature speaker.

I had a chance to ask Rocky a couple of questions that had been bugging me about CSLA.

1)  He agreed that using the method of multiple result sets in datareader is not really a good idea in some instances, where a dataset would be much more useful.

2)  He suggested that you should usually not have an object that is sometimes a child and sometimes a parent.  I am not sure I agree with idea.  I believe I understand his point that if you are dealing with a Project object that has a collection of Employees assigned to it, you probably don’t need the Employees to be as complex as if you were dealing with an Employee who is assigned to a bunch of Projects, but at the same time you are talking about writing 2 classes with 2 sets of data access scripts, vs 4 classes and 4 sets of data access.  But, he said that there are techniques for making a business object be both a parent and a child.  This is apparently detailed in Ch 7. 

Rocky suggested the book Object Thinking by Dave West

3) He mentioned that people have built UI Frameworks that run on top of CSLA.  I will have to look into this.

4) He was showing an example using an ASP.NET MultiView control, looked like a great way to enable multiple views of the same data.

5) I didn’t get a chance to ask him about serialization and deserialization of classes that have small differences.  For example if you serialze an object and use the same byte array to deserialize a similar class, will it blow up if small changes are made, like you add a public property?  I will have to try this out myself.

In all, Rocky was a very good speaker.  Very engaging, funny, and on point. 

Oh and I won the raffle at the end, to get a copy of his book, the one I just paid 60 bucks for :-).

Delete the Web Apps DLLs and Everything Works

Posted on by

Here is another of my favorite problems with VS2005.

If I have a Web Application Project.  If I build it (with no errors) then when I try to view it I get the error below.  However,

Parser Error

Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.

Parser Error Message: The type ‘Company.Web.Equipment.Global’ is ambiguous: it could come from assembly ‘C:WINDOWSMicrosoft.NETFrameworkv2.0.50727Temporary ASP.NET Filesequipment3f386648c5a85b94App_Code.gv_z5p7w.DLL’ or from assembly ‘C:DataCompanyCompany.Web.EquipmentbinCompany.Web.Equipment.DLL’. Please specify the assembly explicitly in the type name.

Source Error: 

Line 1:  <%@ Application Inherits="Company.Web.Equipment.Global" Language="VB" %>

Source File: /Equipment/global.asax    Line: 1

Version Information: Microsoft .NET Framework Version:2.0.50727.42; ASP.NET Version:2.0.50727.42

 

I don’t know why it is only happening with this one web app.

Very frustrating.

Update: This has been resolved.  The problem is obvious now.  This was a web application that had been converted to a Web Site Project.  When I tried to reimport the files manually into a new Web Application Project there was one minor, yet major, difference that was causing it to fail.  The “CodeBehind” attribute had been changed to “CodeFile”.  I didn’t think much of it at the time, but of course this indicates that it is going to actually USE the codefile when the page is accessed.  By having a CodeFile attribute AND compiling the code into a DLL, I was ending up with copies of every class.

App.Config functionality for Class Library Assembiles

Posted on by

I was just reading this site:

http://www.bearcanyon.com/dotnet/#AssemblySettings

I downloaded the sample code (link below).  It is supposed to allow you to have a config file per assembley e.g. MyAssembly.dll.config. 

I haven’t looked at the code, but I guess you would just write something that uses reflection to find the assembly name, and then look for an xml file to read.

AssemblySettings.zip (10.5 KB)

 

Sending Datasets and Objects Over the Wire: Serialization and XML

Posted on by

I have tried to councel against sending datasets across web service calls, but we have a lot of instances where this is being done.

One of the problems with this is that datasets get bloated when converted to XML.

So I set out to compare the sizes of:

  1. Serialized List(Of MyType)
  2. Serialized DataTable
  3. Serialized DataSet
  4. XML Serialized Dataset

I wish I had done some research on this, because I would have quickly been reminded that DataSets always serialize as XML, even if you are using the BinaryFormatter. 

There are lots of people out there coming up with their own ideas for how to improve the serialization of datasets:

Anyway, this isn’t really THAT big of a deal, because my real goal wasn’t to improve the dataset serialization, but to simply see what it would be, and compare it to some other ways to serialize data, like in a list of business objects or a datatable.

The results are interesting:

Given a list of 1013 Business Objects (Records) the serialization results are as follows:

Method Size (bytes)
List(Of MyType) 290,321
DataTable 819,575
DataSet 693,088
XML Serialzied Dataset 851,614

I have read that you can really decrease the size of the dataset by writing your own logic to do the serialization, but as everyone points out that is kind of a pain.

Byte Array To String

Posted on by

Here is a very simple code snippet for converting a Byte Array to a String in VB.Net 

Encoding.ASCII.GetString(bytes)

And here is a function for that uses it to convert a byte array to a string

    
    Private Function streamToString(ByVal stream As System.IO.MemoryStream) As String
        Dim o As New IO.StreamWriter(stream, System.Text.Encoding.Default)
        Dim bytes(stream.Length - 1) As Byte
        stream.Read(bytes, 0, stream.Length - 1)
        Return Encoding.ASCII.GetString(bytes)
    End Function

Implementing System.ICloneable and a Snippet

Posted on by

This will provide the necessary functions to implement ICloneable as well as a type specific Clone method. 

        
        Public Function Clone() As ClassName
            Dim bFormatter As New System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
            Dim stream As New System.IO.MemoryStream()
            bFormatter.Serialize(stream, Me)
            stream.Seek(0, System.IO.SeekOrigin.Begin)
            Dim newClone As ClassName
            newClone = CType(bFormatter.Deserialize(stream), ClassName)
            Return newClone
        End Function
        Private Function ICloneableImplementation() As Object Implements System.ICloneable.Clone
            Return Me.Clone
        End Function

I wrapped this into a snippet that you can import into Visual Studio 2005.

Implement ICloneable.snippet (1.84 KB)

VS.Net 2005 Uses Wrong DLL For Reference

Posted on by

I just came across another bug in VS.Net 2005.

When I went to upgrade some of my projects from 2003 to 2005 I copied them to a new folder.  So for the sake of simplicity lets say that my projects were in C:Projects and the 2005 versions are in C:Projects2005.

Some of the projects had a reference to a DLL located in C:ProjectsMyDLL, so when you run the upgrade wizard, it adds C:ProjectsMyDLL as a reference path for your new project located in C:Projects2005.

Now here is what ticked me off.

I had already taken the code from MyDLL and upgraded it to 2005, built the DLL, and put the DLL in C:Projects2005MyDLL.

So if you convert a project, it doesn’t know about that new 2005 version of MyDLL, so I was nice enough to go in, remove the 2003 reference, and repoint it to the 2005 version.

However, at this point it says “Oh I see you want me to use this DLL, but it looks like there is one with the same (whatever criteria it uses, maybe just the name?) in my reference path (C:ProjectsMyDLL), so I’ll just throw out whatever you were asking me to do and reference that one” which is EXACTLY what I didn’t want it to do.

VS 2005: Remove Project=Lose Reference

Posted on by

I had been really bugged by the way VS.Net 2005 seemed to treate project references.

As I mentioned in a previous post, if you remove a project from a solution, all references to that project are also removed from their respective project.

The result is that lots of project suddenly lose reference to a needed dll or project, and you have to go back and manually add the reference back in.  Big pain.

Thankfully, Mikhail Arkhipov from Microsoft has reassured me that 1) I am not going crazy, 2) this is not by design as in fact a bug, and 3) it will be fixed in a (hopefully soon to be released) service pack. 

Strike 1 issue with VS.Net 2005.  Only like 10 more to go.