Peter Wibeck’s blog

Last weekend I did some cleanup of my Linux machine and transferred all files over to the Windows machine. I ran into problem to transfer bigger files than 4GB so I needed to split the files before transfer and put them back together in the windows machine.

To split a file in Linux to 100MB per piece write:
split –b 100m /path/to/large/file /path/to/output/file/prefix

To put them together again on windows write in the command prompt
copy /b /path/to/output/file/prefix* files.tgz /b

Here is the link to the Beta 1 page : http://go.microsoft.com/fwlink/?LinkId=151799

This is page has a ton of Beta 1 resources such as the Download links, ‘How to download’ video, training kit, walkthroughs, forum links, MSDN library links, featured blogs and link to Connect for bugs.

When I have been looking around on the net about strong naming and signing I have found some confusion about the purpose and the difference between does two methods.

Strong naming
Strong names make names cryptographically strong. When you load banan.dll by its strong name you are saying “load banan.DLL which was signed by XCompany”. The loader verifies that the named dll was signed with the correct key, and if not the loader will refuse to load the dll. This is the only thing that strong naming does (making the name of a dll cryptographically strong). Strong names are not a mechanism for expressing trust decisions. Strong names are just about making a name stronger so that you have a guarantee that the code you are loading at runtime is the code you compiled against. That is the ONLY thing you can safely use a strong name for. Strong name keys go into a “snk” file, which you then typically include with your project.

Certificates signing
Certificates signing are completely different. Certificates form a chain of trust, where a trusted root certificate (Verisign, for example) is installed in every user’s root certificate store. Those trusted root certificates are then used to certify the identities of organizations that issue code signing certificates. This enables the customer to setup trust policies. For example, they can say “I want to trust anything that comes from XCompany”. How will they do that? They first check to see if the dll was signed by an XCompany certificate. But how do they know that the XCompany certificate actually came from XCompany? Because Verisign says so – Verisign signed the XCompany certificate saying “we certify that this dll signing certificate actually came from XCompany”. Why do they trust Verisign? Because  Verisign is part of the Microsoft root certificate program. Acceptance into this program means Microsoft trusts these certificate authorities and places their root certificate in the Trusted Root store on Windows machines. That’s the root of the chain of trust. Certificates doesn’t go into strong name key files, they go into the operating system’s certificate store.

After been spending some tuff days with only reading about user cases and different deployment ways I have finally passed the windows MCPD exam. This is the exam that I think I did learn less from out of the 3 you need to get a MCPD for windows. It was a lot about user cases and testing that I did know most of it already trough my work and universities studies. So I guess the exam was more for people that would like to have paper that they know this things of have not any university degree in computer science.

After 1 month of preparation and a weekend that disappeared I have passed my second MCTS exam. I did use the “MCTS Self-Paced Training Kit (Exam 70-526): Microsoft® .NET Framework 2.0 Windows®-Based Client Development” book for my preparation and Measureup’s online test questions. I did also try ActualTest.com’s question that I did borrow from a friend. I found that the questions many times were almost exactly the same (Found some question with exactly the same options). So I can’t recommend ActualTests.com. Measureup did cover all the areas good except the custom control integration to VS design toolbox and properties dialog. Many questions on the real exam were about this functionality that I had not read about in the book or had any questions about in the practice online tests. So for that area I would recommend to read MSDN.

My study strategy was more or less as last MCTS exam. I did read 1 chapter in the book per day/ every second day (15 chapters in total). I also did plan to do the labs in the book but I never got the time for it. Instead I did concentrate on the lesson and chapter review questions plus the summary in the end of every part of the book. The last weekend that totally disappeared from my life, I did go through all lessons and chapter reviews plus summaries. I also did use the Measureup’s web site very heavily. Went through all 150 questions and read all explanations to all questions (this gave me the most). Another good part with the web questions is that it contain link to relevant MSDN sites for more information.

Measureup
MCTS Self-Paced Training Kit (Exam 70-526): Microsoft® .NET Framework 2.0 Windows®-Based Client Development book

Found a really interesting blog by Michael Feathers today. His goal is to get every programmer from different background up to minimum knowledge bar. The blog contain link to good papers about best practice and other thing a programmer should know as how programming language works.

I recently started to work with Windows Communication Foundation and one of the first problems I did run into was how to use enum type in WCF.

This is a small example of a data contract and a service contract/interface that makes use of the enum type.

using System;
using System.ServiceModel;
using System.Runtime.Serialization;
 
namespace Test.DataContracts
{
    [DataContract(Namespace = "Testing", Name = "JobResult")]
    public enum JobResult
    {
        [EnumMember]
        Passed = 0,
        [EnumMember]
        Failed = 1,
        [EnumMember]
        Running = 2,
        [EnumMember]
        TestFailure = 3,
        [EnumMember]
        Queued = 4,
        [EnumMember]
        JobNotFound = 5
    }
}

Continue reading ‘Using an enum type with WCF services’ »

For a few days I did run into the problem of importing CSV data with OLEDB. The first thing I tried was creating my own parser, but later I found an easy built in way. I show both methods here.

My own parser is simple based on the split string functionality.

//create the table
DataTable dt = new DataTable("Import");
dt.Columns.Add("col1", typeof(string));
dt.Columns.Add("col2", typeof(string));
dt.Columns.Add("col3", typeof(string));
 
//read the data
using (StreamReader sr = new StreamReader(filepath))
{
    int i = 0;
    while (!sr.EndOfStream)
    {
        //skip the header
        while (i < 1)
        {
            sr.ReadLine();
            i++;
        }
 
        string[] text = sr.ReadLine().Split(',');
        DataRow dr = dt.NewRow();
        dr["col1"] = text[0];
        dr["col2"] = text[1];
        dr["col3"] = text[2];
 
        dt.Rows.Add(dr);
    }
}

The build in CVS parser uses a connection string and a SQL query to handle the CVS data. Continue reading ‘CSV parsing using OLEDB’ »

In my work I need to be able to pick different files depending on if I run in 64 bit or 32 bit system. The first thing I did try was to use the size of IntPtr which is 4 for 32 bit and 8 for 64 bit. But since I was using the visual studio unit test framework it did not work that god. The unit test framework run in a 32 bit process but the application I’m testing is running in 64 bit, so decided to use P/Invoke to call GetNativeSystemInfo.

The structure that you get is according to

[StructLayout(LayoutKind.Sequential)]
private struct SystemInfoNative
{
    internal ushort ProcessorArchitecture;
    internal ushort Reserved;
    internal uint PageSize;
    internal IntPtr MinimumApplicationAddress;
    internal IntPtr MaximumApplicationAddress;
    internal IntPtr ActiveProcessorMask;
    internal uint NumberOfProcessors;
    internal uint ProcessorType;
    internal uint AllocationGranularity;
    internal ushort ProcessorLevel;
    internal ushort ProcessorRevision;
}

Out from this you can check the processor architecture.

And the complete source code
Continue reading ‘How to determine if we are running on 64 or 32 bit?’ »

Have you ever wondered how Microsoft does thing inside .NET? Now it’s possible to see the source code by configuring Microsoft reference source server inside visual studio. Just go to ‘Serversetup’ and setup you visual studio 2008 to use symbol files from Microsoft symbol server when you debugging. You can also download the symbol files and use them offline by follow this guide ‘Downloadsetup’.

The symbol files are available for this dll’s in .NET 3.5 SP1.
• mscorlib.dll
• Microsoft.Visualbasic.dll
• system.dll
• System.ComponentModel.DataAnnotations.dll
• system.data.dll
• system.drawing.dll
• System.Web.Abstractions.dll
• system.web.dll
• system.web.extensions.dll
• System.Web.Extensions.Design.dll
• System.Web.DynamicData.dll
• System.Web.DynamicData.Design.dll
• System.Web.Routing.dll
• system.windows.forms.dll
• system.xml.dll