Saturday, May 18, 2013 Register  Login

This site uses DNS Made Easy. Use it for reliable and professional DNS services.

RSS Feeds
Categories
  
Blog Archives
  
Blog

Visual Studio

    Sep
    07

    A while back, I created a little utility to edit ASP.NET membership services database. The instructions only talked about DotNetNuke. I've now added instructions on how to use it on regular ASP.NET membership databases.

    There previous blog post is DotNetNuke user manager - Winform App. The new app is called MembershipUserManager. I've included, as usual, both the source and binaries. The source is now a Visual Studio 2010 solution. It actually uses .NET 2.0, so older versions of Visual Studio and SharpDevelop can use the source.

    The ReadMe.txt file, in the zip files, has instructions on how to setup regular ASP.NET membership and DotNetNuke.

    posted @ Friday, September 07, 2012 10:07 AM by Hector Sosa, Jr

    Downloads:

    Actions:Tweet This Share on Facebook Share on LinkedIn Emakl Permalink del.icio.us
    Jun
    27

    I upgraded Text File Splitter to use .NET 4.0 and Visual Studio 2010. I have been testing different development setups to find the easiest one to get aspiring addins developers up and running quickly. The advantage with .NET 4.0 is that Management Extensability Framework (MEF) comes baked in, and I don't need external assemblies anymore. MEF is what makes it easy to load custom parts into Text File Splitter.

    I've copied the code for the SplitByLine splitting strategy and modified a bit, so that I can treat it as a custom splitting strategy. I named it SplitByLineCustom. Here is how I setup this project:

    I unzipped Text File Splitter 3.0 (not out yet) into the Binaries folder. Then I put the custom project and code in SplitByLineCustom. Here's what the solution looks like:

    Notice that I added a reference to the FileSplitStrategyEngine assembly.

    There's a couple things that need to be setup in the project's properties.

    Set the start action to call the TextFileSplitterUI.exe program. This should be in the binaries forlder that we created in the beginning of this post.

    Point the outpout of your project to the Binaries folder where you unzipped Text File Splitter. Once this is setup, the UI will be able to automatically pick up your custom splitting strategy.

    Here you can see that the custom splitting strategy loaded into this drop down. Here is what it looks when selected:

    I'm fleshing out the SDK. I will be including this solution as part of the SDK. I'm working on getting SandCastle to spit out MSDN like documentation. I'm hoping to have this done in the next couple weeks.

    posted @ Tuesday, June 28, 2011 12:07 AM by Hector Sosa, Jr

    Actions:Tweet This Share on Facebook Share on LinkedIn Emakl Permalink del.icio.us
    Apr
    10
     1815 Views ::  6 Comments RSS comment feed

    I was in the process of updating both PainlessSVN Professional and Console to version 1.2.1, when I found a bug in Visual Studio 2010 debugger. The solutions for both projects were in VS2008. My OS recently died, so I had to re-install it from scratch. I only installed VS2010, because I wanted to move away from VS2008.

    My first hint that something was wrong was when I needed to modify the About dll to include the new version numbers and years in the copyright. This project is a C++ resource dll. This simple project would not compile on the VS2010 compiler when I converted it. I ended up firing one of my VMWare images that has VS2008 to get this done.

    The next thing that happened was that none of the breakpoints I set worked, while trying to track down an unhandled exception. I went to Google and found that this is a known bug. The report is over here:

    Debugging an MMC snapin does not attach correctly to mmc.exe

    The suggested work around is here:

    Can’t hit breakpoints in a plug-in or can’t debug .NET 2.0/3.0/3.5 from a mixed mode .exe project with Visual Studio 2010?

    Unfortunately, that didn't work for me. What did work was to change the mmc.exe instance from the C:\Windows\SysWow64 to the one in C:\Windows\System32, then attach the debugger manually. The debugger will not attach to instances of the mmc.exe program in the SysWow64 directory. I am running VS2010 on Windows 7 Ultimate x64, and that's why I was using the 64 bit version of mmc.exe.

    Anyways, hope this helps somebody else.

    posted @ Sunday, April 10, 2011 10:16 PM by Hector Sosa, Jr

    Actions:Tweet This Share on Facebook Share on LinkedIn Emakl Permalink del.icio.us
    Oct
    09
     2338 Views ::  15 Comments RSS comment feed

    I'm involved in creating a COM interface from a C# 4.0 library. This took a lot of hair-pulling and banging-head-against-the-wall moments. This skillset appears to be quickly disappearing; sad, but quite understandable. I wanted to store how this is done, because I found many little slivers across the Intertubes, but nowhere did I find the slivers put into a coherent picture.

    I'm going to use a simple class that I'm calling ComDog. Here is the definition:

    using System;

    using System.Runtime.InteropServices;

    namespace ComDog

    {

        [ComVisible(false)]

        public delegatevoid DogEventHandler();

        [ComVisible(true)]

        [Guid("2406DD50-A3CE-43A6-9F20-112B621CB784")]

        [InterfaceTypeAttribute(ComInterfaceType.InterfaceIsIDispatch)]

        public interfaceIDogEvents

       {

            [DispId(1)]

            void Bark(); 

            [DispId(2)]

            void Howl(); 

            [DispId(3)]

            void Eat();

        }

        [ComVisible(true)]

        [Guid("8C6DAD17-0612-4166-AD35-3A55DDEAF62E")]

        [ClassInterface(ClassInterfaceType.AutoDual)]

        [ComSourceInterfaces(typeof(IDogEvents))]

        public class Dog : MarshalByRefObject

       {

            public event DogEventHandler Bark;

            public event DogEventHandler Howl;

            public event DogEventHandler Eat;

     

            public void MakeDogBark()

           {

                if (Bark != null)

               {

                   Bark();

               }

           }

     

            public void MakeDogHowl()

           {

                if (Howl != null)

               {

                   Howl();

               }

           }

     

            public void MakeDogEat()

           {

                if (Eat != null)

               {

                   Eat();

               }

           }

       }

    Now let's get this compiled and registered. To get this registered with COM, well need to issue this command, in an elevated command prompt:

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm comdog.dll /tlb:ComDog.tlb

    Now on to Delphi 7...

    Copy both the ComDog.dll and ComDog.tlb to the same folder as your Delphi project. I'm doing this, because I don't want to mess with the GAC.

    In the Delphi IDE, select Project --> Import Type Library. It will look like this:

    This in turn, should show the Import Type Library dialog, that looks like this:

    If you registered the assembly (dll in .NET parlance), you should see an entry for ComDog, like the selected one in the dialog above. Click on the "Create Unit" button. This will add a "ComDog_TLB.pas" file to your Delphi project.

    One important section that I want to direct your attention to:

    // *********************************************************************//
    // OLE Server Proxy class declaration
    // Server Object    : TDog
    // Help String      :
    // Default Interface: _Dog
    // Def. Intf. DISP? : No
    // Event   Interface: IDogEvents
    // TypeFlags        : (2) CanCreate
    // *********************************************************************//
    {$IFDEF LIVE_SERVER_AT_DESIGN_TIME}
      TDogProperties= class;
    {$ENDIF}
      TDog = class(TOleServer)
      private
        FOnBark: TNotifyEvent;
        FOnHowl: TNotifyEvent;
        FOnEat: TNotifyEvent;
        FIntf:        _Dog;

    The events are of type TNotifyEvent, because they do not have parameters. This comes from the IDogEvents. Delphi will ALWAYS use the definition in your event interface, instead of the events listed in the main class. Make absolutely sure that the signature in the event interface match the signature of the events in your main C# class.

    Here is what the definition of the events will look like in your Delphi main form/unit:

    uses
      Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
      Dialogs, ActiveX, ComObj, ComDog_TLB, StdCtrls, OleServer;

    type
      TForm1 = class(TForm)
        btnBark: TButton;
        btnHowl: TButton;
        btnEat: TButton;
        Memo1: TMemo;
        procedure FormCreate(Sender: TObject);
        procedure btnBarkClick(Sender: TObject);
        procedure btnHowlClick(Sender: TObject);
        procedure btnEatClick(Sender: TObject);
      private
        { Private declarations }
      protected
        procedure Barked(Sender: TObject);
        procedure Howled(Sender: TObject);
        procedure Ate(Sender: TObject);
      public
        { Public declarations }
      end;

    var
      Form1: TForm1;
      TestDog: TDog;

    The proctected section above defines the events. This you will have to type manually. Make sure that your _TLB file is listed in the uses section above.

    Now to actually have the events handled, you will have to create a procedure that matches the signature of event. Like so:

    procedure TForm1.Barked(Sender: TObject);
    begin
      Memo1.Lines.Add('Dog Barked');
    end;

    procedure TForm1.Howled(Sender: TObject);
    begin
      Memo1.Lines.Add('Dog Howled');
    end;

    procedure TForm1.Ate(Sender: TObject);
    begin
      Memo1.Lines.Add('Dog ate something');
    end;

    This is how you wire up C# COM events up to a Delphi COM client app.

    The next question is how to deal with events that have parameters. It's basically the same thing. You'll just have to make sure that the signatures for event definitions and event handlers in Delphi, match what's in the _TLB file.

    I did a lot of hair-pulling in order to get this working. I wanted to post this in my blog, for the next time I'm doing this. Please feel free to comment here, if you need more help.

    posted @ Saturday, October 09, 2010 6:34 AM by Hector Sosa, Jr

    Actions:Tweet This Share on Facebook Share on LinkedIn Emakl Permalink del.icio.us
    Oct
    06
     1262 Views ::  2 Comments RSS comment feed

    I was doing a code spike to see if I could get .NET 4 to work with MMC 3.0. All my attempts failed. I googled a bit, and it looks like I'm not the only one.

    In a nutshell, you might get lucky, but for the most part it doesn't work.

    Here's a post on StackOverflow:

    MMC .Net Runtime Version

    Here's the official response from Microsoft:

    Can not use .Net 4.0 to create MMC SnapIn

    Stuff like this is what makes it very hard to trust Microsoft as a developer.

    posted @ Wednesday, October 06, 2010 12:40 AM by Hector Sosa, Jr

    Actions:Tweet This Share on Facebook Share on LinkedIn Emakl Permalink del.icio.us
    Dec
    27

    The UI design has been frozen. I need a couple more tweaks and it will be completely designed and coded. Here's a screenie of the UI having a directory as the source, and the split by line splitting strategy selected:

    I created a new forum group just for Text File Splitter. I already posted a Visual Studio template to create new file pattern tokens on the File Patten Tokens forum. This will install a generic template in Visual Studio 2008, for people who want to create custom tokens. It will look like this once it is installed, from the Add New Item menu:

    I will be doing the same for File Splitting Strategies very soon.

    posted @ Sunday, December 27, 2009 11:11 PM by Hector Sosa, Jr

    Actions:Tweet This Share on Facebook Share on LinkedIn Emakl Permalink del.icio.us
    Nov
    17
     1312 Views ::  1 Comments RSS comment feed

    Justin (who didn't leave a last name) left a comment on how to debug MMC 3.0 snapins in Windows 7 x64 and Visual Studio 2008. I want to put this on its own blog post, so that I can find it easier. I'll just repost Justin's comment here:

    I recently struck this problem with VS2008 on Windows 7 x64 as well.
    I eventually found a solution :)

    The solution is to directly use the 32 bit version of mmc at this path:
    C:\Windows\SysWOW64\mmc.exe rather than the one in System32.
    you still need the -32 flag as in your screenshot.

    When you try and debug via "C:\Windows\System32\mmc.exe -32" what actually happens is the debugger attaches to the 64bit version which starts the 32bit version(in SysWOW64) and then closes itself hence why it stops debugging immediately.

    You can start the snapin that you are debugging on the command line. This is extremely convinient. Here's a screenshot with Justin's findings:

    This is on the project's properties page, on the "Debug" tab.

    Now, if I could just figure out how to get the keyboard shortcuts back. They disappeared a couple days ago, and haven't been able to get them back. *boggle*

    posted @ Tuesday, November 17, 2009 10:41 PM by Hector Sosa, Jr

    Actions:Tweet This Share on Facebook Share on LinkedIn Emakl Permalink del.icio.us
    May
    18

    I got to play with Visual Studio 2010 today, while I was recuperating from a migraine. I didn't see anything revolutionary right away, but I haven't dug in deep yet. The one word I would use to describe it is "pretty." Here are some screenshots.

    This is the Start window. This is what you see when you first fire up Visual Studio 2010 Professional:

    Here is the screen for the Projects link above:

    Here is the screen for the Visual Studio link above:

    And here is what everybody wanted to see, the IDE open with a project. This solution has 22 projects:

    I am running Visual Studio 2010 in a VMWare image running Windows 7 Ultimate. This image had 512 megs of RAM. It was a bit slow, but that's to be expected with that little RAM. I'll make another test with 1 Gig RAM, and see how that goes.

    posted @ Monday, May 18, 2009 7:28 PM by Hector Sosa, Jr

    Actions:Tweet This Share on Facebook Share on LinkedIn Emakl Permalink del.icio.us
    Nov
    09
     1682 Views ::  2 Comments RSS comment feed

    After much work reinstalling Vista and Visual Studio 2008, I found out that I still can't debug 32bit MMC 3.0 snapins in Vista 64. You still need to attach the debugger manually to the running process. Unfortunately, this means that you won't be able to debug stuff while your code is loading.

    I really was not ready to go back to 32 bit, so I compromised by creating a VMWare image that contains Windows XP SP3, Visual Studio 2008 SP1, and all the other necessary dev tools.

    I now have a rig that I know always lets me debug. TortoiseSVN makes it simple to keep my VM and desktop synched.

    Score that a WIN!

    posted @ Sunday, November 09, 2008 11:26 AM by Hector Sosa, Jr

    Actions:Tweet This Share on Facebook Share on LinkedIn Emakl Permalink del.icio.us
    Oct
    29

    Well, I found out that Visual Studio 2005 breakpoints do not work in Windows Vista 64bit. It is a known issue.

    Just-In-Time (JIT) Debugging of an elevated process will fail

    The workaround is to attach the debugger manually. Bummer! I think I'm going to migrate PainlessSVN to Visual Studio 2008. Thankfully, I already have it installed.

    posted @ Wednesday, October 29, 2008 7:31 PM by Hector Sosa, Jr

    Actions:Tweet This Share on Facebook Share on LinkedIn Emakl Permalink del.icio.us
    Page 1 of 2First   Previous   [1]  2  Next   Last   
    Terms Of Use | Privacy Statement | SystemWidgets
    Copyright 2002-2013 by SystemWidgets
    Google Analytics Alternative