I think my employer first started urging me to join Twitter about two years ago. Ever the company man, I did what any forward-thinking technology editor keen to hold onto his job would do. I ignored it.
But if rust never sleeps, Twitter never rests. And it became apparent, even to me, that tweets have emerged as an important stream of up-to-the-minute information and context in the developer space. So with the grudging reluctance of a child told to go clean his bedroom, I signed up. And in the scant few weeks since I jumped on board, I've found Twitter to be enormously useful for staying in touch with our far-flung contributors and for catching the occasional shiny glint coming out of Redmond.
It also occurs to me (belatedly, as ever) that Twitter is a fine way to keep readers apprised of our efforts at Visual Studio Magazine. So I'll be tweeting on our updated how-to columns and news coverage, and offering quick insights into our reporting in the industry.
Interested in following along? You can find me on Twitter as @MichaelDesmond.
Posted by Michael Desmond on 05/25/20111 comments
On April 6, Novell shipped the production version of the Mono for Android development tool, which enables.NET developers to build applications for Android-based devices. Three weeks later, Attachmate finalized its $2.2 billion purchase of Novell. A week after that, on May 3, Mono lead Miguel de Icaza broke the news via Twitter that Attachmate was shuttering the Mono effort and had laid off the entire team.
I interviewed Mono developer and book author Wallace B. McClure about Mono for Android soon after it shipped. With the news that development of Mono tooling had ceased, I decided to go back to McClure and get his thoughts on the sudden turn of events.
Michael Desmond: Were you surprised to learn that Attachmate put the entire Mono crew out on its ear?
Wally McClure: This was a complete shock to me. I heard rumors, but changes tend to happen when a company is taken over, so I didn't think too much about it. Unfortunately, it was hard to figure out what was going on. I watched them ship out updates to MonoTouch after the announcement, so I didn't think too much about it.
To get the phone call that everyone was out was a big shock to me. I was very thankful for that call and it really meant a lot to get that phone call. I wish I had gotten it before I stood in front of about a one hundred people and said that I think that Mono is a good solution for .NET developers, but I can't get everything. We are/were in the final stages of our book [on Mono development], so this threw a wrench into those plans. Thankfully, [my publisher] Wiley is great to work with, so we've already worked out a plan for this.
MD: In an interview with John Waters at ADTmag.com, de Icaza seemed to indicate that his efforts were hampered by Novell. Was there frustration on the part of developers with regard to the pace of Mono innovation on the mobile front?
WM: It's not been a problem with adding new features. The MonoTouch team was very responsive to issues and always had updates out within 48 to 72 hours of users getting a new version of the iPhone operating system. Where there has been frustration is getting the word out that these products exist and that they can be used to produce a mobile application. There are a large number of developers that don't know that MonoTouch and Mono for Android exist. They don't have to abandon C# to get on the iPhone or Android.
While picking up Java/Eclipse to go to Android isn't a killer for most developers, ObjectiveC/XCode is a completely different animal. It contains some pretty stiff learning curves for developers. Getting the message out that a developer can continue with their existing language, C#, and framework, .NET, has been met with shock and surprise by many. The bottom line has been that the lack of marketing money has been the real problem that I have seen with Mono under Novell.
MD: Why do you think Attachmate moved so quickly to shutter the Mono Project?
WC: My personal speculation is that Attachmate looked at the Mono products as bringing in a small amount of money relative to the cost of the team when looked at on a year by year basis. With the shipment of MonoTouch and now Mono for Android, I suspect that they were seeing significant revenue along with a significant growth rate on a month by month basis. Companies think year-to-year, which might be the problem. Entrepreneurs and venture capitalists think of things on a month to month basis plus they look at growth rates.
My guess is that MonoTouch was seeing steady growth and may have been close to paying for a good deal of all the Mono team. Mono for Android had just shipped with version 1.0, so it was just entering the marketplace and I think it had more promise than MonoTouch. I think that this was where the disconnect was, and the value was hidden in the details of profit and loss statements.
MD: It sounds like de Icaza's new startup Xamarin will be forced to essentially re-build the functionality of MonoTouch and Mono for Android. What's the impact on developers like yourself, who have invested in these mobile technologies? Are you back to square one? In short, how much does this whole situation suck?
WM: The impact has been significant at this point. Earlier this week, I had assumed that the interest level in cross-platform .NET would go to zero. As I've talked with you, conference organizers, Wiley and customers, the interest has NOT dropped to zero at all. While there is concern and work is getting pushed back, some work isn't. Miguel and Xamarin have promised that the APIs for the different Mono for iPhone and Android products will be source code compatible. Given that the APIs are driven by iOS and Android, this seems to be entirely possible.
Our plan is to continue with the current MonoTouch product. I suspect that it will work properly up for a while. Once we have a version of the products available, then we'll be able to move forward. Obviously, this has been a delay, but I see it as a delay and not a cancellation. The length of the delay might be shortened if Miguel is able to negotiate for the rights to MonoTouch and Mono for Android.
Posted by Michael Desmond on 05/24/20114 comments
My flight out of soggy Burlington, Vermont won't leave for another 16 hours, but I had a chance to speak this morning with Sean McBreen, Microsoft Senior Director of Visual Studio Application Lifecycle Management, about this morning's keynote and the expanding horizons of ALM under Visual Studio and Team Foundation Server. He echoed many of the points made by Microsoft Corporate VP of Visual Studio, Jason Zander, during his keynote. And I left the call with a four-word summary of Microsoft's ALM strategy rattling around in my mind:
It takes a village.
As Zander and McBreen both pointed out, Microsoft has been focused on ALM to varying degrees back to Visual Studio 2005, when it introduced Team Foundation Server. And that focus has evolved to embrace testers (TFS), designers (Expression Blend), and now IT pros (System Center Connector) and application stakeholders (the PowerPoint storyboard plug-in). In each case, non-developers are being provided rich access to the development stream.
"Collaboration is at the heart of successful software projects," McBreen told me. "The industry legacy has been to force people to work in separate silos and not adapt to the work cycles of individuals or teams."
So Microsoft's strategy, as McBreen put it, is to "meet the users where they aren't," and extend the development lifecycle to those who can help improve the quality and efficiency of software development. Which is why IT professionals can interact with development via System Center and application stakeholders can work with requirements and feedback via browser and a PowerPoint plug-in.
As it turns out, this week's conference is just the place to make this pitch.
"That is why Tech-Ed is a great place to talk about this," McBreen said. "You've got IT pros and developers in the same room."
Posted by Michael Desmond on 05/16/20110 comments
The Tech-Ed Keynote will kick off any minute now. I'll be in Atlanta tomorrow, but for the moment my cohort,
Redmond Magazine Executive Editor Lee Pender, is at the conference to cover the proceedings. You can visit the
Pender's Blog, over at sister magazine
Redmond Channel Partner, for Lee's thoughts on the conference. You can also follow him on Twitter
@leepender.
Not that Visual Studio Magazine won't be covering Tech-Ed from a developer standpoint. We'll be posting our coverage of today's keynote later this morning, and following that up with product coverage as well.
We look forward to a busy week in Atlanta!
Posted by Michael Desmond on 05/16/20110 comments
Gil Fink is a senior architect for the Sela Group and a Microsoft MVP focusing on data platforms. In the May issue of Visual Studio Magazine, Gil wrote a feature exploring the new Code First features in Entity Framework 4.1 ("Not Just a Designer: Code First in Entity Framework"). We followed up with Gil on his thoughts about EF 4.1 and the impact of Code First for .NET developers.
Visual Studio Magazine: Having worked with EF 4.1 and the code first features, what are your impressions of what Microsoft has delivered to developers? Has Microsoft finally filled out the EF feature set, which was obviously not complete in the initial iterations?
Gil Fink: Since EF4 Microsoft is improving the EF stack rapidly and making it a worthy OR/M. There are many other improvements that are needed, such as Enum support, database migrations and the like, but the EF team is working on these features currently. When comparing EF4.1 to EF1. there is a huge improvement in the framework. One last thing is that the EF team is listening to the community and considers things that the community is raising in order to improve the tool.
VSM: Entity Framework has come a long way since the Vote of No Confidence from the MVP Community. Has Microsoft fully addressed the concerns of this constituency? Is there any reason .NET dev shops should hesitate to adopt the technology?
GF: There is no reason for .NET developers to hesitate to adopt EF. The framework is more mature now and includes a vast set of features that puts it in the front line of OR/M tools. Even so, an OR/M solution isn't a silver bullet solution to every problem, and when developers are going to make a decision about whether to use an OR/M or which framework to use, they should invest in a small proof of concept in order to see whether the OR/M solution is suitable to their demands.
VSM: When would the Code First approach be preferable to the Database First and Model First implementations provided in earlier iterations of EF?
GF: The Code First approach is preferable in small to medium applications that you are starting from scratch. It gives the ability to develop the domain model and then uses its conventions engine in order to generate the database. When you have a legacy database already, or a very big database, you probably will want to use the Database First approach instead.
VSM: Microsoft pulled support for pluggable conventions in the final version of EF 4.1. Why was this done and what do .NET developers lose as a result of this decision?
GF: The pluggable conventions were omitted in the release of Code First because the EF team wanted to wrap up the EF 4.1 package and the pluggable conventions were still in development. This was a major decision that the team took, since pluggable conventions were meant to enable the developers to plug their conventions into the Code First built-in convention engine, and by that provide an important extension point. We will probably have to wait to the next EF version in or to get the feature.
VSM: Any advice for developers looking to migrate to EF 4.1? How can they prepare to ease the transition for their existing applications and databases? Are there any common mistakes that they should look to avoid?
GF: The migration into EF 4.1 is very easy. Since EF 4.1 is built upon EF 4 and only adds new features to the EF stack, then all the developers need to do is to install the package (using NuGet package manager or downloading it from here) and use the new feature sets. There are new improvements in EF 4.1, such as the lightweight DbContext and DbSet that the developers will need to learn about, but nothing is going to change in the other feature sets of EF4.
Posted by Michael Desmond on 05/12/20110 comments
Microsoft on Tuesday
confirmed that Scott Guthrie, corporate vice president of the .NET Platform, was moving to assume control of the new Azure Application Platform group. The transfer has big implications for the .NET developer community, which has benefited from a host of advances during Guthrie's tenure in the Developer Division at Microsoft.
Rob Sanfilippo, analyst at research firm Directions on Microsoft, praised Guthrie's work and reach at Dev Div. "Scott Guthrie is highly regarded by the developer community, and he exudes a perception of influence and knowledge across all of Microsoft’s developer platforms and tools."
But developers are understandably concerned about the move. Wrote one reader of the early reports (by blogger Mary Jo Foley) that Guthrie might be leaving: "Scott Guthrie moving to the Windows Azure team? Say it isn't so! I sure hope it's a false rumor!"
Alas, Microsoft itself soon confirmed the rumor, though the company seemed anxious to blunt one avenue of concern about the decision.
“His move does not indicate changes to Silverlight development that were outlined back in early April and at MIX," said a Microsoft spokesperson when asked about Guthrie's transition. "Microsoft’s commitment to Silverlight is strong, both for the Web and Mobile applications."
While questions about the many projects launched or led by Guthrie will no doubt linger, most Visual Studio Magazine readers seemed anxious to see what the former .NET Platform head can do in the Azure group.
Wrote VSM reader Steven James: "I am very pleased to hear of Scott's move. As a developer, I thought up until now that the Azure team was not getting what us developers need to create product for it. A 30-day trial just does not cut it for a developer. Scott's take will be welcomed. One simple task should be the following: Make it FUN for us to develop with Azure and make it affordable for developers."
Developer Shahzad Sarwar, who said he is looking forward to Guthrie's "good work in the Azure domain," also railed against the 30-day limit.
"I once tried to explore Azure but can't move forward because of trial limitations. Microsoft should give more space to developers of Azure," Sarwar wrote.
Another developer, who identified himself as Mike, hoped Guthrie can get Microsoft to create "an Azure Express version for developers to thoroughly kick the tires on Azure. Make a very small version available for free for devs so we can test code and features without the worry of getting a credit card charge or running out of trial-time. We don't need a lot of CPU or database size to test our code, we just want the barrier (cost and trial time-limit) removed to try this out."
He continued: "SkyDrive gives 5 GB for free. SQL Server Express is free. SQL Compact 4 is free. VS2010 Express is free. Let us play for free, and then we can pay for it when we're ready to publish real sites."
What are your concerns as Guthrie moves from the Developer Division to his new position with the Azure Application Platform group? And what would you like to see Guthrie accomplish in his new role? Email me at [email protected] or leave a comment below.
Posted by Michael Desmond on 05/05/20115 comments
So Mary Jo Foley was right. Scott Guthrie, corporate vice president of the .NET Platform,
is gone. He'll be heading up the newly created Azure Application Platform team at Microsoft, reporting to Ted Kummert, senior vice president of the Business Platform Division.
Microsoft hasn't said much yet, but the memo that Mary Jo Foley obtained makes it clear that Guthrie will be asked to bring his developer relations mojo to an Azure platform looking for some spark.
Wrote Developer Division Senior Vice President S. "Soma" Somasegar in the memo: "Given the strategic importance of Cloud Computing for STB and Microsoft, we need a strong leader to help drive the development of our Cloud Application Platform and help us win developers for Azure."
A statement from a Microsoft spokesperson in response to my inquiries about the move yielded this tidbit: "Cloud computing is strategically very important for STB and Microsoft. We needed a passionate leader for bringing developers to the Windows Azure platform."
There's more than a little dog-whistle PR going on here. The use of the words strategic, leader and developers is far from accidental.
On the one hand, I don't like this move. Scott Guthrie has been a phenomenal creative force for Microsoft over the years, driving vast improvements in the developer tooling and infrastructure even as he has emerged as a powerful advocate for developer interests. His work with open source software and providers in the Developer Division pre-dated Microsoft's change of heart on the issue by years. As a result, Guthrie has emerged as a true star in the .NET development community. There is no way the Developer Division won't miss Guthrie's leadership.
On the other hand, I expect big things out of the new Azure Application Platform group over the next few years. Guthrie wasn't brought in to make the donuts. As Mary Jo Foley noted to me earlier today, some intriguing teams will fall under Guthrie's purview, including the Web Platform and Tools team and the Application Server Group. "[It] makes me wonder what kinds of new tools and dev stuff they have cooking," she wrote in an email exchange.
That's an important point. If Guthrie can spin the same kind of magic he did at DevDiv over the years, Microsoft could build a strategic (there's that word again) competitive advantage in the cloud space. So while I might not like what Microsoft is doing here, I sure agree with how they plan to go about it. I can see no better way to build an absolute groundswell of Azure support than to set Scott Guthrie loose on the developers who will build and leverage Azure applications and infrastructure.
What will the new Developer Division org chart look like? Details are scarce, but the internal memo notes that the Client Platform team led by Kevin Gallo will report directly Guthrie's former boss, Somasegar. The .NET Core Platform team will now report to Jason Zander, corporate vice president of the Visual Studio Team in the Developer Division. I hope to get a clearer picture on how the movement will impact the DevDiv soon.
What do you think of Microsoft's decision to move Guthrie from his pivotal position in the Developer Division to lead the new Azure Application Platform team?
Posted by Michael Desmond on 05/02/20117 comments
I suffered a rude surprise when I came across
this blog item from All About Microsoft blogger (and Redmond magazine columnist) Mary Joe Foley. She says that Scott Guthrie, corporate vice president of the .NET Platform at Microsoft, may be moving to the Windows Azure team as part of a larger May 1 reorg in Redmond.
Of course, Guthrie needs no introduction among Visual Studio Magazine readers. The man's fingerprints are on virtually every surface of the .NET development stack. He has been instrumental in the success of the .NET Framework development platform, pushing a courageously open and pragmatic strategy of developer interaction that has made his group one of the leading lights in Redmond.
And now Scott Guthrie may (and I stress, may) be heading off to work on Windows Azure.
This would be great news for Microsoft's cloud business. The move has a bit of a Sinofsky Effect about it. Steven Sinofsky was nailing it as head of the strategically important Office business for Microsoft, but Redmond decided it needed its best general to tend to the struggling Windows client franchise after the drawn out debacle with Windows Vista. The result was Windows 7.
I'm confident Guthrie would do a great job running the Azure business, in large part because he would quickly energize the partner community around the platform. Guthrie at Dev Div has made .NET development enormously attractive and compelling for developers with a lot of choices available to them, and he's done it by marshalling both his own resources and those of the broader dev community. By the same measure, I expect Guthrie (provided he has full reign to do so) would be able to forge a more coherent and palatable message around Azure, and to drive the feedback loop to enable Azure to separate from cloud competitors.
But I cant help but wonder what such a move would mean to the .NET development community. Guthrie isn't just a capable and effective manager, he's something of a visionary. While high profile stars like Ray Ozzie floundered in their efforts to articulate and promote a vision of what Microsoft would bring to the community, Guthrie delivered. He spearheaded the movement into open source solutions, and enabled levels of interoperability and openness that were leagues ahead of other Microsoft units.
We shouldn't get ahead of ourselves here. This may be a rumor and nothing more. And Guthrie may spend the next 10 years driving the .NET development stack at Microsoft. But if such a move is in the offing, it will be very interesting to see how the Developer Division evolves and the role it takes going forward.
What's your take on this rumor? And how important do you believe Guthrie to be to the success of .NET and the Developer Division at Microsoft? Email me at [email protected] or leave your comments in the space below.
Posted by Michael Desmond on 04/27/20112 comments
Want to start a fight? Ask a bunch of .NET developers about their opinions on the relative merits of the Visual Basic and C# programming languages. If the activity in our comments section is any guide, the discussion can quickly shift from a high-minded analysis of lambda expressions and XML literals to a shouting match over who makes the most money.
Like so many great rivalries, the contretemps between VB and C# are borne out of proximity. Since 2002 the two languages have shared a common foundation in the .NET Framework, and for the past two years have drawn closer together thanks to Microsoft's co-evolution strategy. In the May issue, we look at Redmond's decision to abandon the effort to differentiate the two languages, and explore how a future of feature parity may impact developers' language choices down the road.
Also in May you'll find Gil Fink's exploration of the new Code First features in Entity Framework 4.1. As Microsoft's Scott Guthrie blogged last year, code-first development in EF "enables a pretty sweet development workflow" that lets developers create domain models without using a visual designer or .edmx file. Finally, Todd Anglin of Telerik offers insight into the opportunities (and challenges) around reusing Silverlight code across desktop and Windows Phone 7 platforms.
Visual Studio Magazine Tools Editor Peter Vogel is at it again this month. He writes a hands-on review of Visual Studio 2010 Service Pack 1, and also provides a data access deep dive with his Practical .NET column on speeding up data-related operations in .NET applications. On VB columnist Joe Kunk offers a detailed tour of the LightSwitch application development environment, and Mark Michaelis kicks off his new UI Code Expert column with advice on structuring complex Visual Studio solutions.
Roger Jennings is on board in May, writing a VS Insider column that takes aim at the debate over NoSQL databases for Web scale applications. Could SQL and NoSQL be a lot more complementary to each other than we all think? Finally, Andrew Brust implores Microsoft to young it up and be more public and vocal about things like its cutting edge research efforts.
Even as the May issue prepares to hit the street, we're looking for your input for June, July and beyond. What issues or topics would you like to see covered in the next issues of Visual Studio Magazine? Email me at [email protected], or leave a comment below.
Posted by Michael Desmond on 04/26/20110 comments
Today at VisualStudioMagazine.com we're debuting a new, monthly column dedicated to open source tooling and development in .NET. The Open Source .NET column, written by Ian Davis, delves into the fast evolving arena of open source development tools. Ian is the Master Code Ninja for software architecture and development consulting firm IntelliTechture and an expert on the .NET Framework. He's also a frequent industry presenter and co-organizer of the Spokane .NET User Group.
The new column recognizes the important changes that have occurred at Microsoft, and in particular in the Developer Division, over the past few years. From Microsoft's early support for the DotNetNuke project in 2002 to its deepening commitment to jQuery in 2011, we've seen open source software assume an important role in .NET development.
It's a role Ian Davis has recognized. As part of his first column, on the open source NuGet package management system, I asked Ian to provide a bit of an introduction:
I have been working with open source projects for many years and I look forward to continuing that for many more. It has been an enriching experience both reading and writing code, collaborating via developer mailing lists, and participating in community discussions. I believe that the open source landscape is getting better and more important every year. Working with open source projects has greatly increased my exposure to new ways of thinking about software and improved my skills as a developer.
The goal of most open source projects is to design and implement powerful, reliable solutions to issues we face every day, and then share them with the world. There is a great deal of competitiveness and camaraderie among projects and their contributors that promote the betterment of the projects and the community. In our work as developers, we often encounter problems of significant size. Many times these problems have been solved a number of different ways in open source projects, thus giving one the ability to cherry pick the best solution from these candidate projects. This leverages the great deal of effort that went into writing these components and saves both time and money.
Many open source projects are sponsored by corporations, including Microsoft. Microsoft even actively works to promote a number of these open source initiatives. Their recent MIX11 conference included an open source track with a number of projects represented. They both sponsor a range of projects from project management and code hosting (codeplex.com), and also promote collaboration on and distribution of existing projects, such as jQuery, Orchard, WCF Web API and ASP.NET MVC.
One of Microsoft’s latest contributions to open source, NuGet, handles package management, which has long been missing from the .NET landscape. This project changes the way we work with components in our applications and reduces the friction we feel when installing and upgrading our component stack.
Read Ian's first Open Source .NET column here.
Posted by Michael Desmond on 04/20/20110 comments
Novell yesterday
shipped the production version of its MonoDroid .NET application development tool for Android devices. Rebranded Mono for Android 1.0, the new release includes a Visual Studio 2010 plug-in and SDKs for building Android applications.
I posed a few questions to Wallace "Wally" McClure, a partner at Scalable Development, Inc. and author of three books related to Mono-based development (including the upcoming Professional Android Programming with MonoDroid and .NET/C#, expected in July). He's also written about MonoDroid development for Visual Studio Magazine (Introduction to MonoDroid and Building a MonoDroid App). Here's what he had to say.
Michael Desmond: What noticeable or meaningful improvements can developers expect in the 1.0 release?
Wally McClure: I've watched the Mono for Android product evolve since the first preview bits in August 2010. It's been great to watch the problems slide away. I think the biggest improvement from the last few weeks are:
First, the API is considered to be fairly solid. Assuming that you write to the defined API, your mobile application should upgrade [fairly easily] as the Mono team roles out new versions.
Second, you can deploy apps to the app store. While we all like to play with pre-release products, it's hard to go that final step and deploy applications to end users based on a product that has the terms beta or "pre-release" associated with them. By removing this, it says that the Mono team feels confident that you can deploy an application to end users without the fear that your application will fail based on something in the Mono framework.
MD: What are your thoughts on what the Mono folks have delivered with MonoDroid 1.0? What might a .NET developer new to MonoDroid expect from the tooling and what limitations might they encounter?
WM: I think that the 1.0 release is a good foundation. It has support for .NET 4, which developers are using. It has support for Web services, databases, android services, and many of the features that developers will expect.
Building a user interface in Android requires patience, and Notepad, until recently. Google has started to address this in their tools, and developers have always been able to use a tool like DroidDraw for defining their user interfaces, due to the xml format of Android user interface files. One of the surprising features in Mono for Android is the IntelliSense [support] for building a user interface within Visual Studio.
When you deal with Microsoft on an issue with their development tools, due to their size and widespread acceptance in the marketplace, they are under tremendous pressure to make sure that any changes, such as service packs, are only sent out at defined times. This can mean a long wait for a fix, but the Mono team can get updates out in a much quicker timeframe.
For example, with the Mono for Android 1.0 release that shipped this week, there was a problem in my voice recognition and driving direction app. This application worked perfectly in the final preview two weeks ago. Joe Hill from Novell emailed me about a small update on Wednesday evening. I installed it and my voice recognition and driving direction application worked properly again.
What I am getting at is that the Mono team is able to address issues quickly and get those fixes out to the marketplace. This has happened with MonoTouch and I suspect that this will happen with Mono for Android as well.
This biggest limitation that I have found is that the Android emulator is definitely wanting. This is something outside the control of the Mono team. I wrote a pair of blog posts on how to get around this: Android Emulator - Increasing Performance Suggestions for MonoDroid and The Android Emulator Keyboard
MD: Any thoughts on the Visual Studio integration and how effective it is?
WM:I think the Visual Studio integration is a good first step. It allows Mono for Android to fit into the Visual Studio ecosystem easily. Overall, I have found it to work very well. I am able to write an Android application and run it in the emulator or on a device and see what is happening fairly easily. The only plug-in that I use is SVN and Mono for Android integrates with it perfectly. Other people in the mailing list are reporting that Visual Studio plug-ins work properly.
Admittedly, the Mono for Android debugging integration is problematic in the 1.0 release. Many users, myself included, are reporting poor performance and numerous timeouts in Visual Studio debugging. I fixed this when I got an update to my four-year-old development system. I suspect that the debugging will improve shortly similar to how MonoTouch initially shipped with no debugging support, and about six weeks afterwards the Mono team shipped an update with debugging support.
MD: What stands out as a key flaw or missing feature of the new release?
WM:I think the biggest missing feature at this point in time is the lack of a visual designer. Most developers are familiar with the concepts and greatly depend on them. A design surface allows a developer to get up to speed quickly. But a design surface is not perfect, and many advanced developers don't use them. The beginning developer can work around this by using DroidDraw to get up to speed. It's not an "in the box" solution, but it's a solution none the less. I used DroidDraw when I started with Mono for Android last summer in this exact scenario.
Posted by Michael Desmond on 04/07/20118 comments
Not to
lean on the topic of the Visual Basic .NET programming language, but earlier this week I had a conversation with Navot Peled, president of code migration tools provider Gizmox. His company's Visual WebGUI tool enables developers to move existing, rich-client applications to the Web or cloud.
The company just recently announced it was partnering with Tata Consultancy Services in Israel to provide a joint solution for migrating Visual Basic 6 and other legacy applications to .NET. The timing is no coincidence. Microsoft apparently has no plans to include the VB6 runtime with Windows 8. And with extended support for VB6 long since retired (back in April 2008), the risk of continuing to maintain even stable VB6 code starts to go up.
Even companies that are happy with their VB6 code bases face pressure to move on, said Peled. "Some of those organizations can not go on using an unsupported platform. From a banking perspective, the regulations won't allow it."
The problem is, the inventory of VB6 code out there is big. Really big. Like, 25 billion lines of code big.
"If you look at the business side of it, we are talking about around 25 billion lines of code in VB6," Peled said. "If you look at the customers that are running VB6 at the moment, one of them is the biggest bank in Israel. It is a core application."
So what advice did Gizmox have to offer? Itzik Spitzen, vice president of Research and Development at Gizmox, said organizations moving from VB6 to VB.NET or C# will face a multifaceted challenge, as they work through significant changes error handling and transition to an object-oriented programming environment.
"There are many technical challenges when it comes to reusing the code and taking it from VB6 to the .NET environment. It gets slightly easier to move to VB.NET, because VB.NET supports some of the old features and configurations as is," he said. "But if you really want to move in a way that takes full advantage of the environment and .NET, then the challenge gets much larger."
Spitzen said developers moving from traditional client-server build outs must be aware of the data limitations of Web and cloud deployments, as well as challenges that arise when application logic may be accessed by an unpredictable number of users over the public network.
"When we do this type of project we often find ourselves reengineering this specific part in order to improve the scalability of the application," Spitzen explained. "We have smart decision making tools, to control the size of data sets, etc. But people are often mistaking that."
Are you managing VB6 applications today, and if so, what are your plans going forward?
Posted by Michael Desmond on 03/30/201113 comments