This tip isn't really migration-related, but I've used it so many times these past few days that I think it is worth sharing. We work with virtual machines A LOT, using Virtual Server 2005 R2 SP1. Every once in a while you need to log into a server using Terminal Services to delete old VHDs to make room for a new one, opr just for any other miscelaneous task that can't be done through the web administration client. And, unfortunately, sometimes there are two terminal services sessions open already, so you get the following error:
"Terminal server has exceeded maximum number of allowed connection"
You then stare at your monitor in frustration for a few seconds. After that, you figure out who the culprit is and ask him politely to "PLEASE LOG OFF".
Well, after discovering this tip, there is no longer a need to stare at your monitor or to ruin your relationship with your coworkers. Turns out there are a couple of command line tools you can use to close remote Terminal Services sessions. They are available in both Windows XP and 2003. The first one, qwinsta, lists all the open sessions on a particular server:
c:\>qwinsta /server:192.168.123.123
SESSIONNAME USERNAME ID STATE TYPE DEVICE
console 0 Conn wdcon
rdp-tcp 65536 Listen rdpwd
jpena 1 Disc rdpwd
administrator 3 Disc rdpwd
In this case, you can see that Juan Peña (user jpena) has an open session in the disconnected state. In order to close his session, you need to use the second tool, rwinsta:
rwinsta /server:12.12.12.12 3
This command will kill the session with ID 3 (jpena's). And voilà! After this, I'm able to connect to the server. :-)
Credit goes to Scott Forsyth's WebLog.
A quick post to tell everyone that the day finally came: Windows Server 2008 was released today. You can find more information about it on the Windows Server 2008 page, and watch the keynote here.
The biggest deal, from my perspective, is Hyper-V. This will have a significant impact on the IT market, by exposing thousands of IT profesionals to a hipervisor-based virtualization solution. Another very interesting technology is RemoteApp, which allows you to use, through Terminal Services, just one application instead of the complete desktop. It solves a deployment issue that required expensive software solutions in the past - and something we run into every once in a while when determining the best deployment strategy for migrated Informix 4GL applications.
During migration to C# or .NET it is easier to keep the same ActiveX.
The VBCompanion does a great work in migrating the ActiveX control using the .NET ActiveX wrappings and fixing all method calls.
Sadly sometimes those ActiveX do not work properly in .NET.
Well we have good news.
Recently my friend Jose David (who we keep bothering because he is now
a Project Manager and now he only programs in MS Excel and MS Project, I added the MS by his request :P) fixed a curious bug
we had with an aplication we migrated from VB6 to C#.
The thing is that the aplication had an ActiveX control with a strange runtime behaviour.
We migrated the application keeping the ActiveX control and in most ocasions it worked ok.
But randomly it started throwing exceptions.
During the testing he discovered that if he repeated the steps slowly the bug did not reproduced.
So his idea was that it was due a garbage collection issue. And SURPRINSINLY he was right :P
He added this:
System.GC.Collect();
System.
GC.WaitForPendingFinalizers();
And the application started to work.
It seems like some of the COM objects needed a little more time for releasing all references :)
Hi, for several months I lived with an extremely unconfortable bug.
On some pages IE will display an alert dialog indicating
Error
A Runtime Error has occurred.
Do you wish to Debug?
Line: blablabla
Error: blablalba
Well finally I looked in google and found this: http://support.microsoft.com/kb/822521
So if anybody had to live with this bug like me, I hope this helps him
Here is a valuable comment I received. So I'm adding it so it will help somebody else.
I was plagued by the "Runtime error - do you wish to debug?" problem for months
and finally resolved it last night, after testing everything else in the MS knowledgebase
to no avail (http://support.microsoft.com/kb/308260/ln/).
The problem disappeared instantly after a tip-off elsewhere to install & run SpyBot. (Looks like my SpywareBlaster 4.1 failed me there.)
So it wasn't:
my IE 7 settings (Disable script debugging),
operating system (XP Pro SP3),
firewall (Comodo Pro),
antivirus (Avast!) or
scripting engine (WindowsScript 5.7) - just Spyware
Now that Visual Studio 2008 is available, you might wonder what will happen with the Visual Studio 2005 projects generated with the current version of the VB Upgrade Companion (VBUC). For starters, it is worth mentioning that Visual Studio 2008 fully supports projects created in the .NET Framework 2.0, like the ones generated with the VBUC. The newer version of the .NET Framework (3.0, shipped with Vista, and 3.5, shipped with VS2008) keep the same core version of the CLR (2.0) as before, with very few minor changes. There are no compatibility or breaking changes like when upgrading from versions 1.1 to 2.0 of the .NET Framework.
When you open a VS2005 project in VS2008, you are greeted with the new Visual Studio Conversion Wizard:
Once you click Next, you can select whether to create a backup of the project or not. I chose to NOT create a backup, since this is a copy of the project, since I will be comparing both .csproj files later on. Press Next.
The next step tells you what will happen during the conversion:
Press Finish, and after a little while, the process will be complete:
You can check out the Conversion Report afterwards. For most projects, however, the reports should be in blank:
So there you have it. After converting this test VS2005 Windows Form application, I was able to continue working on it without any issues. It is true that the code generated by the VBUC will not take advantage of all the neat features of the .NET Framework 3.5, such as WPF, but you should be able to continue working with the migrated code after moving to Visual Studio 2008 without any problems.
.... and so we reached 2008. This may seem like any other "average" year - the price of gas keeps going up, everybody talks about global warming, and will be an election year in the US (so we have one more reason to stop watching TV). However, for a large group of IT departments around the world, 2008 is a BIG year. 2008 is the year when Microsoft officially kills support for Visual Basic 6.0.
It took a while, but as in Chronicle of a Death Foretold, everybody knew it was coming. Microsoft's Product Family Life-Cycle Guidelines for Visual Basic 6.0 details the different support stages VB has gone through:
...
Mainstream Phase
The Mainstream phase will be in effect for six years after the product's general availability date. Visual Basic 6.0 was generally available in January 1999. Mainstream support will end March 31, 2005.
Extended Phase
The Extended phase will be in effect from seven to nine years after the product's general availability date. Extended Phase support begins in April 2005 and ends March 2008.
Non-Supported Phase
Visual Basic 6.0 will no longer be supported starting March 2008.
If you are still using Visual Basic 6.0, however, there is no need to despair. According to the Support Statement for Visual Basic 6.0 on Windows Vista, the VB6 runtime will be supported in Vista for at least 10 more years (5 of mainstream support + 5 of extended support). The IDE, however, will be unsupported from April 8, 2008. And you will be missing all the new technology shipping with the .NET development tools - web services, WPF, managed code, etc. There is, however, an easier way to move away from VB6 quickly...
You can use the Visual Basic Upgrade Companion to move your application quickly and effectively from VB6 to either Visual Basic .NET or C#. Our experience in migration projects shows that by using the VBUC, you can drastically reduce the time it takes to move your application to the .NET Framework, reducing the risk vs. a complete rewrite, and keeping all your business rules, but in a modern platform that will allow you to use the latest technologies moving forward.
You can find more information on the Visual Basic Upgrade Companion here.
Since 2007, a team of ArtinSoft’s
experts has been working on a tool that helps automate a lot of actions commonly
performed by web developers, increasing their productivity and resulting in more
efficient pages. The outcome is Aggiorno, an
expandable plug-in for Visual Studio that produces SEO friendly, XHTML compliant,
CSS styled HTML and ASP.NET, which eases enormously the task of delivering web
standards compliant web sites. Based on a unique pattern detection and
transformation engine, Aggiorno’s beta version is currently available on a
by-invitation-only basis, so register now
and get early access to this revolutionary product!
Happy 2008!
During last year, ArtinSoft has also been working on a new product that we called Aggiorno ( www.aggiorno.com ). Aggiorno is a Visual Studio add-in designed to increase the productivity of web developers. Aggiorno helps developers with a broad range of topics like web standards, SEO (Search Engine Optimization), Accessibility, XHTML, ASP.NET, etc.
If you want to know more about aggiorno you can visit our new web site or the official blog: www.aggiorno.com\blog .
In this blog, I will continue to discuss Visual Basic Upgrades and its implications. By the way, customers are increasingly getting more excited about the speed and safety of migrations vs rewrites.
There has been a lot of controversy around the end of Visual Basic 6.0, a
language that was generally available since January 1999. Opposition is
comprehensible when you take into account that there is a huge VB 6.0 code base
out there. But when you look at Microsoft's Product Family
Life-Cycle Guidelines for Visual Basic 6.0, it is ultimately a very large
orphaned code base.
On previous posts, I've mentioned the End Of Life of VB6, referring
specifically to the official support phase. Microsoft's Visual Basic 6.0
support policy has been in effect since the release of Visual Studio .NET. The Mainstream
Phase, where standard support offerings were available (professional
telephone and online incident support, free critical updates and free online
self-help tools), ended on March 31, 2005. The Extended Phase began in
April 2005 and will end on March 2008. During this period, that is,
at this moment and for the next couple of months, standard support offerings
are still available, including Premier Support, paid telephone and online
incident support, and free online self-help tools. Free telephone and online
incident support is no longer being provided, and critical updates are
available for a fee.
Starting on April 2008, Visual Basic 6.0 will enter the Non-Supported
Phase, where support will no longer be offered by Microsoft. The Visual
Basic 6.0 family of products includes the Standard, Professional, and Enterprise editions of
Visual Basic 6.0. It also includes users of Visual Basic 6.0 who obtained their
licenses via Visual Studio 6.0 Professional and Enterprise editions.
Of course, you may be able to find support elsewhere; with such
a large code base, the community is a viable source for support. There is a lot
of self-help tools and content out there: articles, how-to guides,
troubleshooting information, frequently asked question lists, webcasts, and
more. But this might not be enough for companies with business critical
applications and/or subject to regulations, or ISVs whose customers will demand
the latest technologies without doubt.
End of support doesn't imply that you can't continue using the product; it
doesn't mean that the IDE will stop working, but it signifies that any existing
or new defects are unlikely to ever be fixed. You will not find any new Service
Packs, which keeps your product up-to-date with the latest collection of fixes
for the core product and components, since Microsoft stopped delivering these
after the Mainstream Support Phase. Finally, in the Non-Supported Phase, no
security fixes will be provided at all.
In the end, all this is only natural. There have always been
advances in software development capabilities, and the history of Microsoft's
Visual Basic has been no different. For example, for VB4 Microsoft introduced
32-bit address spaces. But in going from VB6 to VB .NET Microsoft did far more
than that. It re-wrote the whole product: VB.NET is, in essence, a totally new
programming language. It bears some superficial resemblance to VB6, but
underneath it is entirely predicated on the .NET Common Language Runtime (CLR)
and its data types; and at compile time, you have to use the .NET framework.
Visual Basic .NET is clearly a better language, with its improved error
handling and a much better development tool in Visual Studio. It's also
multithreaded and a true object-oriented programming language, which limits
backward compatibility.
Software assets represent a competitive advantage, and keeping up to date
with the latest technologies is crucial in today's business environment.
Precisely, Microsoft disclosed those guidelines to provide the advanced notice
required by many to make accurate information-technology and product planning
decisions within their organizations. So this is the time to stop developing
legacy applications in VB6 and assess the remaining VB portfolio for
modernization options. It might not be a trivial task, but there are VB to .NET
migration products and services that can definitely
ease the process.
Just a quick post to wish all readers a happy and prosperous year 2008! :)
For those of you who missed it, Windows Server 2008 RC1 was released yesterday, with the Beta of Hyper-V. Finally!
You can download it here, and there is some more information on the Virtual PC Guy's WebLog.
AJAX applications are great
Their coolness factor is high, and your clients
will be trilled by the new interactivity of your pages
But as a developer when you have a problem with
AJAX it could be hard to track. Because there is
a lot going on behind the scenes
Some of our costumers migrate their ASP applications to
to ASP.NET and it's natural that they want
some AJAX in it.
So I found a GREAT GREAT application for AJAX debugging
It's called fiddler. I cannot describe it all for you so go its site and watch the videos
The tool is just amazing :)
It really can see everything that the browser
receives and sends and more.
A definitive must
Fiddler
Even though most of our clients are from the US and Europe, lately we have been getting more and more projects in Latin America, specially in Mexico. You’ve probably heard about a large project we started in Mexico recently. We also signed two smaller projects in the last month, and last week I was on-site at a customer in Mexico D.F. working on yet another one.
The thing is that in Mexico, even though still in Latin America (remember that we are based in Costa Rica), there were a couple of cultural differences that really caught my attention.
First of, the schedule. We in Costa Rica usually have lunch between 12 and 1. In Mexico it is usually between 3–4pm, 3–5pm or 2–4pm, depending on the company. That is a bit late for us… let’s just say that by 3pm I was starving.
The second one was the dress code. Normally in Europe and in the US, IT departments are very laid back, and have a very lax dress code. Through out Latin America, however, it is mostly suit and tie. Only in a few places can you show up with “business casual” or even “casual” clothes. This is changing, though, and going more and more casual.
All in all, going to Mexico was a nice experience. The people I worked with were really nice, and treated me well (other than keeping me hungry until the mid-afternoon 
). I hope we sign this project, so I’ll be able to go back!
One of the
questions that most people ask when preparing for a Visual Basic 6.0 migration
to .NET has to do with the difficulty level of migrating an application to C#
compared to VB.NET.
Although the Visual Basic Upgrade Companion product can migrate VB6 code to both VB.NET
and C#, and both languages are first-class citizens in the .NET world, having
access to all the resources provided by the .NET Framework, there are some key
differences that will make a migration to C# demand more manual effort and
changes. The following are two of these differences:
- C# is
strictly typed as opposed to VB6 and there’s no way around it. Invoking a property or method
from an Object variable that is meant to be instantiated to a different
type at runtime would require a type-cast; otherwise the compiler will
throw an error. Therefore, many late-bound operations and unsafe
operations (such as assigning the value of a Long variable to an Integer
variable) that unfortunately were common in VB6, will generate compilation
errors. This will not happen in VB.NET unless you turn Option Strict on,
which is turned off by default.
- In C#,
only Structured Error Handling (“Try Catch”) is allowed. This means that any error-handling
code that could not be converted to “Try Catch” by VBUC will have to be
fixed manually, implying an important amount of manual work in some
projects (especially if statements such as “On Error Resume” and “On Error
Resume Next” are used in the VB6 code). On the other hand, VB.NET still
supports Unstructured Error Handling (“On Error GoTo”) for compatibility
with migrated applications, which will reduce the amount of manual work if
you are in a hurry. For VB.NET migrations, VBUC can disable the
conversion of “On Error GoTo” to “Try Catch” to speed up the migration
process and reduce manual changes.
Naturally,
strongly-typed and well-structured code is preferable. However, this increases
the amount of manual work that is needed to achieve Functional Equivalence.
More information on migrating Visual Basic 6.0 to C# can be found in the ArtinSoft
website:
http://www.artinsoft.com/vbc_csharpgen.aspx
One of my purposes for this year was to start
using more the MSBuild
Saldly I'm still not as good on it as I expected
This link provided some interetings points
MS Build and VS
Recently a friend at work had a problem querying a SQL server that indicated
that the column name was wrong.
The only thing wrong was the the case. For example he had COLUMN1 instead of
Column1. I had never seen that problem in SQLServer.
I had seed that in Sybase but not in SQLServer. He solved that by changing the
database collating sequence to something like this:
alter database database1 collate
SQL_Latin1_General_CP1_CI_AI
the CI in the collating indicates Case Insensitive
For more information on SQL Server collations check:
http://msdn2.microsoft.com/en-us/library/aa258233(SQL.80).aspx
And you determine your current database collation use a code like this:
USE
yourdb>
GO
print
'My
database ['
+
db_name()
+
']
collation is: '
+
cast(
DATABASEPROPERTYEX
(
db_name(),
N'Collation'
)
as
varchar(128)
)
print
'My tempdb
database collation is: '
+
cast(
DATABASEPROPERTYEX
(
'tempdb',
N'Collation'
)
as
varchar(128)
)