And so it begins – any suggestions on where to start?


The Visual Studio Professional Indigo Tools team has officially started our epic journey into the Orcas product cycle!  Woot.  What makes this team and product cycle so exciting though is that we (the Indigo team) are mixing things up and trying this ‘crazy new agile jazz’ (http://agilemanifesto.org/).  More specifically we are using Scrum with UserStories.  (I’m actually the one who pushed the idea to the team, and will be acting as ScrumMaster.)


 


So far we have defined a Product Backlog of the features we would like to deliver in Orcas and “Visual Studio Orcas + 1”, and so the process now turns into a game of prioritization.  With Scrum we know our features will be shippable every 30 days.  So what order do we bring features online?  Ideally we will target the Community Technology Previews, so that we can get feedback from you as soon as possible.


 


I ask the question then, what would you – blog viewer slash Indigo consumer – like to see in our first CTP?  Is the final UI the most important?  Configuration of bindings?  What about being able to see how well Visual Studio can consume MSMQ services?  The Indigo feature set is absolutely gimungus so getting your feedback on how we can provide the right level of functionality is key.


 


Please use the Contact link above to let me know your thoughts.  I’ll forward it on to our super-PM John Stallo.


 


Until next time, remember: Windows Communication Foundation 4 Life!


 

Comments (6)

  1. Norman Diamond says:

    This has already been discussed to death elsewhere but since you ask I will answer here too.  Microsoft has been a big pusher of Windows CE devices, .Net Framework including .Net Compact Framework, and C++/CLI including compatibility between C++ and .Net Framework.  However, Microsoft hasn’t been a big pusher of using all of these at once — in fact Microsoft prohibits it.  Microsoft has already promised that Orcas also won’t allow this combination.  This is one promise for which some of us wouldn’t mind if Microsoft breaks it.

    Some of us might also wish for service packs for existing versions of Visual Studio to be given a higher priority than betas of future bugs, so that we might have a more cooperative development environment this year and next.

    We might also hope that there will be some sort of migration tool that actually works for the amounts of Visual Basic 6 code that exists in the real world, that will yield real code that .Net programmers will really be able to work with.

  2. ChrSmith says:

    That’s some good feedback.  It is easy for a feature team to focus on their customer segment but lose sight of the end-to-end-to-end-to-end scenario 😉

    A lot of work has been a lot of work on VB6 code coverters, is there something in particular you are experiencing?  Like a library or control that isn’t making the transition into the managed world?

    Thanks,

    -Chris Smith

  3. Norman Diamond says:

    > A lot of work has been a lot of work on VB6 code

    > coverters, is there something in particular you are

    > experiencing?

    I haven’t tried the VB6 converter that probably exists in Visual Studio 2005, but around a year ago I tried Visual Studio 2003’s converter on around 15 projects where I had done some improvement work for a customer in VB6.

    The customer’s code was originally written in VB4 and converted 100% seamlessly from VB4 to VB6.  (The seamless conversion included a few bugs that probably behaved identically in VB4 and VB6.  Only one caused undue amounts of trouble in tracking it down.  I guess it hadn’t impacted the customer previously because they had used some particular string fields only for part numbers and things like that, and had only used single-byte characters in those part numbers.)

    VB 2003’s converter did the obvious stuff like changing type Integer to Short and Long to Integer.  It croaked on fixed length strings in user defined types (VB’s phrase for structs).  It croaked on calls to DLL functions with user defined types for arguments.  It croaked even worse on ever user-visible form in every project.  Every form would have to be redesigned from scratch in order to use VB 2003.

    In VB6, the default size for a font is 9.  9 whats I’m not quite sure, but it’s 9.[*]  If I need to squash more characters into a button caption then I can set the size to 8.  In a real emergency I can set the size to 7 but most characters are unreadable at that size.

    The converted project had almost all button captions truncated.  I don’t recall the exact numbers but I think that for each font size 9 in the original designs, VB2003 was showing 9 in the designer but storing 8.25 in a file, and for each font size 8 in the original designs, VB2003 was showing 8 in the designer but storing 6.75 in a file.  If I used vim or Notepad to edit the file then I could set it to 7.5 and the button label would look OK, but if I ever opened it in VB2003’s form designer it would get ruined again.  In a few cases where we needed to shove in a few more characters the size as stored in the file had to be 6.75 which the designer showed as 8.

    Of course a few items such as form titles and notifications to the machine operator were shown in larger sized fonts.

    Anyway, in order to use VB2003, every form would need some tool other than VB2003 in order to repeat the design of every form and then be used when updating any part of any form.

    Eventually I learned how to pass arguments to DLL functions when they were user defined types containing fixed length strings.  Never found a way to make it easy though, without any equivalent for "As Any".

    I just regard VB– as being unusable.

    [* Someone on the internet told me the default is 8, but that’s because the internet includes more than just Japan and this was someone who had never used VB6 in Japan.]

  4. Norman Diamond says:

    Forgot to mention one more nontrivial part of the conversion attempt.

    The original code had a lot of calls to functions in a DLL that had been written in VC++.  As I sort of hinted at, the void* and length parameters were handled using As Any and the LenB function (which, even though it didn’t always count bytes correctly, at least existed).  I forgot to mention that these really were function calls, not method calls.

    I wrote a new DLL with a COM object and method calls to do the same, as far as I could guess, as the original DLL.  (The customer didn’t have their C++ source code any more but oddly the function names and parameter names were good enough to make it pretty clear what each function was doing.)

    Besides the need to convert each LenB call to something in the MarshallAs class or something like that, and observing outright lies in MSDN pages about TCHAR counting characters not bytes when the fact was it counted bytes not characters, and finding some way to accomplish an As Any (I forgot if I found a way or not), it was also necessary to convert every call from doing a function call to naming an object and doing a method call.

  5. ChrSmith says:

    Thanks for the info.  I would reccomend you try the Visual Studio 2005 VB6->VB.Net converstion tool to see if it fixed some of those issues.

    I’ll forward your issues to Paul Yuknewicz, a Program Manager on the VB team and guru of all things conversion. If there are still issues blocking your conversion in 2005, he’s the guy who will make sure they won’t block you in our next release.

    Thanks again,

    -Chris

  6. Norman Diamond says:

    OK, among the approximately 15 projects in this collection, I ran the converter on one that is average in complexity.  In Visual Studio 2005, menu File – Open – Convert, and choose Basic.

    Font handling looks like it’s been improved.  Button labels look OK, including those where I squashed the font a bit to shove in a few extra characters.  Though I really ought to try creating a few new buttons to see if new button labels can get the same font sizes.  Some other controls still got ruined though, such as carefully sized and located MSFlexGrid controls.  Some buttons that used to be positioned just below the bottom of a flexgrid are now sitting on the flexgrid, obscuring some of the data.

    Arrays are still handled abominably.  More than 40 years ago the industry knew how to make compilers generate object code using the subtraction operator so that the lower bound of each array dimension in source code didn’t have to be 0.  C didn’t take advantage of that because C was a replacement for assembly language.  Once upon a time Microsoft did know how to copy this innovation.  But now Microsoft no longer remembers how to generate IL code using a subtraction operator.  Where I had an array dimension from &H1000 to &H119F, now it runs from &H0 to &H119F.  It must be admitted that this probably won’t cause crashes, it will only waste memory.  But in some projects it’s natural to have array bounds starting with negative numbers, if the programming language didn’t originate as a replacement for assembly language.

    Every call to a DLL function failed to be converted.

    Every call to the formerly built-in function LenB failed to be converted.

    The converter generated an upgrade report with 304 compile errors, 171 design errors, 524 warnings, and 3 other.  By default the report is expanded one level deep.  I suppose it’s possible to expand the [+] signs to view other levels, but it’s not working by default.  Today I’m going to hesitate to click on Internet Explorer’s warning bar which says the page contains dangerous contents.

    Maybe it would be possible to fix this up from its present state in a length of time competitive with starting a new project from scratch.  But I think it would take more than a day just to investigate and prepare such an estimate.

    By the way my previous statement about VB– being unusable was a mistake.  For new projects of course it’s usable, though not as usable as it should be.  Sorry I forgot to consider that case.  Only for older existing projects VB– is unusable.