Getting ASP.NET Development Server (WebDev.WebServer.exe) on Vista
 

by Sameera on April 04, 2009 12:51

I came across a weird issue today with my ASP.NET Dev Server. I’m running Vista Home Premium with Firefox set as the default browser. I was consistently getting a “Failed to Connect: Firefox can't establish a connection to the server at localhost:<port>.” error. Little bit of Goolge pointed me to several posts suggesting that I turn off IPV6 on my network adapter. Hmmm… Nope! Idea I know a better way to fix this (fingers crossed). Navigated to %SystemRoot%\system32\drivers\etc (C:\Window\system32\drivers\etc on mine). Opened up hosts file in notepad. Commented out the following line:

::1             localhost

 

It now it looks like

#::1             localhost

Save the file, restarted Firefox and Dev Server (not sure whether I needed to even do that). Presto! It works! High Five!

Codoxide Library | Updates and New Home
 

by Sameera on November 15, 2008 21:08

I have made several updates to the Codoxide.Common Library and moved the project over to SourceForge.net.

The project's new home is codoxidelib.sourceforge.net and the new SVN repository is https://codoxidelib.svn.sourceforge.net/svnroot/codoxidelib/trunk

Codoxide.Common Library Version 0.0.1 (Concept Phase): Database Wrapper, Basic Design Patterns, Configuration Handlers
 

by Sameera on October 20, 2008 11:18

Today I'm so excited to announce the first release of the Codoxide.Common Library. High Five! I haven't been over ambitious about the version numbering as I want you to treat this library to still be in concept stage.   Codoxide.Common Library Released

Unfortunately, this release had taken longer than expected cos of my newly cramped up schedule. Worst part of that is I'm posting this code without proper documentation (yep, excuses!). Nevertheless, there's plenty of code in here to prove useful to many. So here goes!

Features/Components

Patterns

  • SharedInstance<T>
  • Singleton<T>
  • Factory e.g. Factory.Build<T>()

Configuration

  • ConfigurationManager<T>
  • ConfigurationSectionBase

Data

  • Database<CONNECTION_TYPE, COMMAND_TYPE, ADAPTER_TYPE>
  • Map<T>

 

SharedInstance<T>

SharedInstance is actually the most basic type of generic Singleton implementation that's been around in the C# community. This implementation was both simple and efficient. But, it violated the definition of a Singleton by depending on the presence of a public constructor and thereby allowing additional instances to be created. Therefore, I have refrained from calling this a Singleton resorted to the term SharedInstance.

E.g:

[code:c#]
SharedInstance<User>.Instance.Login("admin", "password");

User employee1 = new User();
employee1.Username = "emp001";
employee1.Password = "pass001";
employee1.Save();
[/code]

Singleton<T>

More advanced implementation of the generic Singleton implementation. Uses reflection, custom attributes and "lazy initialization" to provide a powerful way to create and initialize your singletons.

E.g:

[code:c#]
public class UserPreferences : IXmlSerializable, ISupportLazyInitialization
{
    ..

    public virtual void Initialize()
    {
        try
        {
            string location = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) + "\\Codoxide\\preference.xml";
            if (File.Exists(location))
                using (XmlReader reader = XmlReader.Create(location))
                {
                    reader.ReadToFollowing("Preferences");
                    this.ReadXml(reader);
                    reader.ReadEndElement();
                }
        }
        catch (Exception ex)
        {
            throw new InvalidConfigurationException("Exception occurred while loading the preferences from disk", ex);
        }
    }
    ..
}

...

Console.WriteLine(Singleton<UserPreferences>.Instance.BackgroundColor);
[/code]

Factory.Build<T>

This one's another powerful and unique implementation. Coolest feature of this class is that you can do something like the following:

[code:c#]
using (IDatabase db = Factory.Build<IDatabase>())
{
    ..
}
[/code]

This allows developers of class libraries to write their code using interfaces or abstract classes, leaving the library users to specify the concrete classes via configuration files.

Grab the Code

There's of course, plenty more to be documented regarding the library. And you can expect the project space to be updated in coming (err..) weeks Wink.

Until then, you can:

Check out the code (using SVN): https://codoxidelib.svn.sourceforge.net/svnroot/codoxidelib/trunk

Browse the project space: http://codoxidelib.sourceforge.net/

Updating the Database Wrapper for C#
 

by Sameera on June 19, 2008 04:52

I have made a few updates for my Generic Database Wrapper class. The update contains a bug fix along with several additional methods for supporting DbParameters.

The new source file can be downloaded here. I have also updated the file linked to the original post.

VSTO App Deployment using NSIS - Part 2
 

by Sameera on May 21, 2008 02:28

Detecting and Deploying Prerequisites

This is the 2nd of a multi-part series on deploying VSTO Applications using NSIS. Part 1 of the series can be found here.

Step 4: Ensuring MSI 3.1 is available

Before proceeding you need to make sure the client computer has MSI 3.1 installed. Click here to find out how.

Step 5: Checking whether Excel is Installed

Being an Excel Worksheet-Level Customization, it makes no sense for this app to be deployed on a computer that doesn't have MSO Excel 2003 Professional installed. Lets see how we can achieve this. If you do a bit of research you can find out that with VS Deployment Projects, this is achieved by doing a Windows Installer search for the component ID {A2B280D4-20FB-4720-99F7-40C09FBCE10A}.

Since performing a Windows Installer Search is a common and desirable feature, I came up with the following macro:

!macro GenerateMsiSearch functionName componentId
    Function ${functionName}
        Push $0
        Push $1
        StrCpy $0 ""
        StrCpy $1 ""
        System::Call "msi::MsiLocateComponent(t '${componentId}', t, *i) i .r1"
        DetailPrint "Component ID: ${componentId} Install State: $1"
        ${If} $1 == '3' ; installed on local drive
            StrCpy $0 '1'
        ${ElseIf} $1 == '4' ; run from source, CD or net
            StrCpy $0 '1'
        ${ElseIf} $1 == '-3' ; Path  to the component returned more data than our buffer can handle. Which means we do have this installed.
        ${Else}
            StrCpy $0 '0'
        ${EndIf}
        Pop $1
        Exch $0
    FunctionEnd
!macroend

When invoked, this macro will generate a function, with the give name that will search for the specified Component ID. So the code to detect Excel 2003 becomes:

!insertmacro GenerateMsiSearch "IsExcelInstalled" "{A2B280D4-20FB-4720-99F7-40C09FBCE10A}" ; Version 2003

Section "MainSection" SEC01
    ; Determine whether the user has the required version of Excel installed
    Call IsExcelInstalled
    Pop $0
    ${If} $0 == '0'
        MessageBox MB_OK "A compatible version of Microsoft Office Excel was not found. Setup cannot continue."
        Abort
    ${EndIf}

[/code]

So, why did I make this a macro that generates a function, and not just a function that accepts the component ID as a parameter? Well, parameter passing is not that straight forward with NSIS, and I believe this leads to much cleaner code at the end.

Step 6: Ensuring .NET 2.0 Runtime is Present

You can find plenty of ways to do this on NSIS web site. Here's one of them.

Step 7: Ensuring VSTO is Present

!insertmacro GenerateMsiSearch "IsVstoInstalled" "{D2AC2FF1-6F93-40D1-8C0F-0E135956A2DA}"

Function InstallVSTOSE
    ; ${DirState} '$COMMONFILES\Microsoft Shared\VSTO\8.0' $1
    Call IsVstoInstalled
    Pop $0
    ${If} $0 == '0'
        SetOutPath '$TEMP'
        SetOverwrite on
        Banner::show /NOUNLOAD "Microsoft VSTO SE..."
        File 'C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\vstor\vstor.exe'
        ExecWait '$TEMP\vstor.exe /q:a /c:"install"' $1 ; '$TEMP\vstor.exe /q:a /c:"install /q"' $1
        Delete '$TEMP\vstor.exe'
        Banner::destroy
        ${If} $1 == '0'
            DetailPrint "VSTO 2005 SE was installed successfully."
        ${ElseIf} $0 == '3010'
            SetRebootFlag true
        ${Else}
            DetailPrint 'VSTO 2005 SE Installation failed with error $1'
            Abort
        ${EndIf}
    ${Else}
        DetailPrint 'VSTO 2005 SE already installed.'
    ${EndIf}
FunctionEnd

We now have the scripts in place to deploy the application components as well as the to determine all prerequisites are available. All that is left is to add the boiler place Update Manifest and Set Security code. Easiest way to do this is to bring the code over a new .NET EXE project and pass the installation-dependent (e.g. Installation Path etc.) parameters as command line arguments. You can then execute the EXE as the last step of the installation.

Tags: , , ,

Filed Under: Code Snippets | Projects

About Me

Sameera Perera

Sameera Perera

Log in

RecentComments

Comment RSS

Calendar

<<  March 2010  >>
MoTuWeThFrSaSu
22232425262728
1234567
891011121314
15161718192021
22232425262728
2930311234

Archive

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2010

All forms of source code published on Codoxide.com are distributed under the Apache License, Version 2.0 unless otherwise stated.
The rest of the content are published under a Creative Commons Attribution 3.0 License.
Creative Commons License

CodoxideTM

Copyright © 2010  codoxide.com. All rights reserved. Designed by Sameera Perera