.NET v1.1 - the bleeding edge of technology



  • I work on a pretty big application written in almost nothing but C++.  The UI is MFC with VS2003.   The next feature I’m assigned to involves a complete overhaul of a handful of dialogs. 

    I wasn’t looking forward to beginning a new round of the fuck-ton of tedious work required to make a decent GUI in MFC, so I spent a few days figuring out how to call into a C# DLL and implemented a bit of the new functionality.  My plan was to do it quick enough to convince the powers that be that using C# would be a huge improvement in quality and development speed.

     The initial reaction I got was confusion and my boss left by saying he would talk to his boss about it.  The final answer was basically “No.  It would be too difficult to explain using a new technology to the customers.”

    Sigh.  I need a vacation.



  • @noitcif said:

    ... so I spent a few
    days figuring out how to call into a C# DLL ...
    Using Managed C++ must be out of the question, or you'd simply have written the UI with System.Windows.Forms in C++ instead of either using MFC or needing a C# dll. So, you must mean setting the ComVisible attribute in C# and using the standard C++ COM API, right? If so, then the WTF is that it took a few days to figure it out. If not, then the WTF is probably whatever you ended up doing.



  • @Jaime said:

    Using Managed C++ must be out of the question , or you'd simply have written the UI with System.Windows.Forms in C++ instead of either using MFC or needing a C# dll.

    I went down that path but ran into some problems that I'd rather not describe. But one problem was compiling with /clr required turning off "Enable Minimal Rebuild."  It takes something like 30 minutes to do a clean build.

    @Jaime said:

    So, you must mean setting the ComVisible attribute in C# and using the standard C++ COM API, right?

    Right.

    @Jaime said:

    If so, then the WTF is that it took a few days to figure it out.
     

    @noitcif said:

    I spent a few days figuring out how to call into a C# DLL and implemented a bit of the new functionality

    Why do you assume I spent the majority of the time figuring it out?

    @Jaime said:

    If not, then the WTF is probably whatever you ended up doing.
     

    Meh



  • Sorry, I read that as:



    (I spent a few days figuring out how to call into a C# DLL) and (implemented a bit of the new functionality)



    ... instead of ...



    I spent a few days figuring out how to (call into a C# DLL and implemented a bit of the new functionality)



    In my defense, if you want it to read the second way, you have to substitute "implement" for "implemented", otherwise your second clause has verb tense confusion. Wow, I didn't realize how much fun this whole pedantic dickweedery thing was until I tried it.



  • Pedantic dickweed! :)



  • @Jaime said:

    Sorry, I read that as:

    (I spent a few days figuring out how to call into a C# DLL) and (implemented a bit of the new functionality)

    ... instead of ...

    I spent a few days figuring out how to (call into a C# DLL and implemented a bit of the new functionality)

    In my defense, if you want it to read the second way, you have to substitute "implement" for "implemented", otherwise your second clause has verb tense confusion. Wow, I didn't realize how much fun this whole pedantic dickweedery thing was until I tried it.
    There is even a third way to read it:

    I spent a few days (figuring out how to call into a C# DLL and implemented a bit of the new functionality)

    But then you'd need the present participle, i.e. "implementing"...



  • You could just as easily take your current project and convert it in your own free time (if you want to, that is).


  • ♿ (Parody)

    @noitcif said:


    My plan was to do it
    quick enough to convince the powers that be that using C# would be a huge
    improvement in quality and development speed.

    The initial reaction I got was confusion and my boss left by saying he would talk to his boss about it. The final answer was basically “No. It would be too difficult to explain using a new technology to the customers.”

    TRWTF is finding stuff like this in your post: <p class="MsoNormal"> <span style="mso-spacerun:yes;">

    But more seriously, it sounds like these guys have previously witnessed or participated in the process of, "We're going to rewrite this with a newer betterer technologiy. It's going to be awesome!" And then suffered through all of the regressions and heartache that inevitably follow. Not that I don't sympathize with you and the task that you face. But following what you want to do seems to lead to two separate paths:

    1. A Frankenstein's application of mixed frameworks and languages. This is quick and relatively easy to start with, but overall maintenance is more difficult, and just gets much worse over time. Just setting up a dev environment got a lot harder, not to mention distribution and installation to end users.
    2. A nightmare rewrite before the benefits of the newer methods start to pay off.


  •  @boomzilla said:

    A Frankenstein's application of mixed frameworks and languages. This is quick and relatively easy to start with, but overall maintenance is more difficult, and just gets much worse over time. Just setting up a dev environment got a lot harder, not to mention distribution and installation to end users.

    I see what you're saying, but does it always have to evolve in to the nightmare you described? My plan was to have one new DLL that gets packaged with the installer, and no dev environment would need to change at all.  My utopian dream was...

    1. Implement new features using C#

    2.  When a complete rewrite of a feature becomes necessary do it in C# instead of C++

    3. If the coupling to other parts of the system is too great in 1 or 2, stick with C++


  • ♿ (Parody)

    @noitcif said:


    I see what you're saying, but does it always have to evolve in to the nightmare you described? My plan was to have one new DLL that gets packaged with the installer, and no dev environment would need to change at all.  My utopian dream was...

    1. Implement new features using C#

    2. When a complete rewrite of a feature becomes necessary do it in C# instead of C++

    3. If the coupling to other parts of the system is too great in 1 or 2, stick with C++

    It seems to me that right now, you simply need VS2003 + MFC. Maybe that is guaranteed to have the C# and .Net stuff that would be required. I'm not familiar enough with the tools involved, so maybe that's not an issue.

    If this is really a "big" app, then the nightmare of a rewrite is probably a near certainty. Can anyone produce examples of large apps that had a smooth rewrite?

    From a developer's perspective, I'm right there with you on the desirability of junking difficult to maintain legacy code. But still, even seemingly simple refactorings can cause regressions or other new problems that aren't at all obvious. Moving from one language to another is a much bigger change. From the manager's perspective, muddling along is a much lower risk strategy. Of course, I don't know the details of this particular app, or what sort of plans there are for it, so it's hard to judge based on what I know, but your bosses' default opinion on this isn't at all unreasonable from the business perspective.


  • :belt_onion:

    @noitcif said:

    @Jaime said:

    Using Managed C++ must be out of the question , or you'd simply have written the UI with System.Windows.Forms in C++ instead of either using MFC or needing a C# dll.

    I went down that path but ran into some problems that I'd rather not describe. But one problem was compiling with /clr required turning off "Enable Minimal Rebuild."  It takes something like 30 minutes to do a clean build.

    It's been a while since I have done a similar project, but you wouldn't compile the entire existing C++ project against the CLR. You'd just create a new wrapper DLL in managed C++ that links into the existing native C++ DLL. (Or link statically against a lib)... probably should repeat that it's been a while :)

    I do understand why your boss doesn't like it because all of a sudden you depend on both the C++ run-time AND the .NET run-time which adds a new dependency on the .NET framework into your installer



  • @boomzilla said:

      Can anyone produce examples of large apps that had a smooth rewrite?

    They are rare, but do happen. Last year my firm converted a C++ program (which was a "C" program, which was a Pascal program, which was a Cobol program) over to C# (thankfully not 1.1).  To make things more challenging, the origianl developers (of the C++ version) were long gone, there was not documentaion, no unit tests.



  • @boomzilla said:

    Can anyone produce examples of large apps that had a smooth rewrite?

    Do you call 600kLOC large?  That's the largest project that I've been part of that went smoothly, completed on time, and delivered a not just ported-and-rewritten app but also a substantially improved feature set and reliability at least as good as the original.  The main reason it succeeded so well can be put down almost entirely to one factor, that management gave us a realistic schedule; 18 months.  We had time to do it right, so we did.



Log in to reply