VB + C# Adventures (Part 2)

We’re using Visual Studio 2010 so all of my gripes, comparisons, etc will be based on that. 

The biggest thing I noticed right off the bat is in the IDE.  C# Intellisense is kind of clunky compared to its VB counterpart.  I found this kind of weird…

C# Syntax

I’m finding myself using parentheses where I should be using brackets, but it’s rare. 

I miss the With construct that’s in VB.

I sometimes declare my variable name before the type.

Semi-colons…don’t forget those!

Curly-braces galore!

I find the syntax to be a bit more cryptic.

 

VB Syntax

More verbose, but I find it easier to read (this is just personal preference I guess).

Gotta love direct access to My.Settings and My.Resources.

No need to break after every case in Select (Switch) statements.

Delegate parameters need an AddressOf identifier when passing into a method, whereas C# you just pass in the method.

VB + C# Adventures (Part 1)

I’ll be starting a new series documenting my experiences with using VB and C# simultaneously.  This isn’t meant to be a comparison between the languages, but rather just a non-technical (as can be anyway) dump of the things that are going through my head as I use both languages.  I’m sure this has been done before, but this ought to be fun anyway.

Some personal background…

Back when I was in college, I learned C++ as my first language.  Of course there was some minor SPARC assembly (like I really remember any of that…) and later Java as required by whichever classes I was taking.  I had extremely light exposure to VB6 in my senior year in one of my design classes.  We did UML diagrams and we tied it into a VB skeleton with absolutely no requirement to write any code.  I literally wrote zero lines of VB code in that class.

My first professional job was at a mortgage company and the environment was VB6.  It didn’t take long for me to get adjusted, but I found VB6 a little odd as it went against most of the guiding principles I learned in college as to how to write a program.  Anyway, I’m not going to jump onto the “bash VB” train because that train is full…

Since VB6 was on my resume, my proceeding jobs were also related to me using VB6.  I didn’t mind it, but at the same time I wasn’t really learning anything new… I guess you can say that I started getting bored. 

Fast forward to my current job.  When I first started here, I had zero professional experience with .NET.  I’ve always wanted to get into it, but opportunities seemed slim for me given that I had no professional experience in .NET (catch 22…, but it’s worse for game developers).  I did do some studying on my own in C#, but I wasn’t about to lie and say that I had real-world .NET experience.  I was very fortunate to come across a job listing for my current position and also for the fact that Greg gave me a shot.

Jumping from VB6 to VB.NET wasn’t difficult.  I guess it was because I had retained some of the objected-oriented knowledge from college and the syntax between the two wasn’t too different.  I was (and still am) excited to learn something new for a change.  So far, doing things in C# isn’t too difficult for me.  I had some prior experience with C-style syntax already and I know the .NET framework from doing things in VB.NET already.

I feel that a good carpenter can build a great house with any brand of tools you give them.  The same holds true in the case of a good .NET developer (or any developer for that matter).  A good or bad developer will be a good or bad developer regardless of what language they are using.  This is why I really don’t understand the C# snobbery I see a lot of.  Both languages have their pros and cons, but in the end it’s the result that matters.

Visual Studio 2010, When “Save All” Doesn’t Mean “Save All”

I found a minor bug related to the Save All functionality while updating our build definitions.  A new project was added to our TFS and this needed to be cloaked for all of our existing build definitions.  No problem, just add the path, set it to cloaked, and copy the line so you can easily paste it in your next build definition without having to pick the path. 

I did this for five of our definitions and I decided to go back to the first one for some reason to double check.  Why didn’t the path get saved?  I hit Save All and didn’t get a prompt when I closed the build definitions, so what gives?  Okay, maybe it was a glitch or something so I did it again, this time I tried using the regular Save instead of Save All.  This time my build definitions were updated. 

It seems like there’s a bug with Save All and updating build definitions.  I submitted the issue to Microsoft, but they want a video… I’m always wary about submitting anything work related to the public domain so I had to decline.  Hopefully the issue gets resolved, but in the meantime if anybody else is having the same issue, just hit Save instead.

The Reappearing Breakpoint (VS2010)

Today I somehow made VS2010 crash in the middle of debugging.  After I reopened my project, I noticed that a breakpoint that I had deleted previously kept on showing up.  Needless to say this was quite confusing since I removed it.  No problem, I’ll just remove it again…

Whenever I ran my application in debug mode, the breakpoint would magically reappear! I thought maybe it was a glitch, so I just closed and reopened my project.  F5 and why is it reappearing when I just deleted it?  Okay, I’ll just shut down VS and reopen it… F5, OMG why won’t you go away?! 

Debug->Delete All Breakpoints fixed it… life’s a glitch.

VS2008 to VS2010 Upgrade Notes

UPDATE 6/23/2010:

The issue with one of our setup project builds has been successfully resolved with a workaround that I thought didn’t work at first.  It turns out our Microsoft contact couldn’t reproduce the issue.  It was the end of the day so I decided to shelve this issue until this morning.  I tried running the setup project from my XP machine with the workaround and it worked.  More importantly, I ran it on our build machine and it worked!  The thing that threw me off was that it failed on my Windows 7 development machine, which is where I initially tested the issue.  I suspect it might have to do with the fact that the interop assemblies were actually built on my old XP development environment and that something isn’t jiving now when I use the same assemblies to build on my Windows 7 machine.  In any case, copying the interop dlls to the same path as the vdproj file works like a charm.

 

 

Using the latest and greatest development environment is always fun.  However, upgrading from a previous version isn’t always easy.  When we converted our dev environment from VS2005 to VS2008, there were a number of headaches to get everything working properly.  So far, upgrading to VS2010 from VS2008 is proving no different.  Since we’re still on TFS2008, we used this workaround to build VS2010 solutions on our Build machines. 

So after our build machines had VS2010 installed and the above MSBuildPath workaround was applied, I ran my first build.  It was a ClickOnce build and it actually ran without any issues.  The application compiled and everything got copied over to our drop location…Cool!  So then I tried running our MSI build for the same project.  I was expecting it to build fine since the ClickOnce build is a little bit more complex, but the MSI build failed.  After thoroughly checking all settings in the Setup project, I couldn’t figure out why it was failing.  The only reason in the BuildLog.txt was EXEC : error : Unable to update the dependencies of the project.  Could the message be a bit more vague, please?

After searching the web, it seemed others were having the same problem.  The workarounds suggested on that page didn’t work for us.  So instead of waiting around, we decided to open up a support ticket, which our contact at Microsoft is currently looking into.  I had a feeling that Interop assemblies in our project might be causing the problem, but it wasn’t until today that my suspicion was gaining ground.  We have a few projects that have MSI builds, so I went ahead and converted and built those out.  What do you know?  The MSI builds that don’t have Interop assemblies build fine on our build machine.  We’re still waiting for a real solution to this problem, until then, we’re building the MSI package locally for that one project.

Another one of our builds has unit tests.  I ran this project’s build without the unit tests first and it completed.  I then ran the build with the unit tests and 99.9% of the unit tests failed, but not all of them, which was weird to me.  These unit tests passed completely when we were using VS2008, so maybe the MSTest reference needed to be updated or something.  I searched MSDN and found this post about the same exact issue we were having.  I tried the solutions suggested, but they didn’t work.  There were some other odd issues with the build with the unit tests, so I just decided to delete the workspace associated with that build.  After I did this, the unit tests passed and everything looked good.

I hope when we upgrade our TFS2008 to TFS2010, that there aren’t going to be more issues.  I have my fingers crossed…

Running an Interactive Application Through a Windows Service

Have a need to run an interactive application through a Windows Service?  I do and I did a LOT of searching on the Internet and the answer I found was that it can’t be done anymore ever since Windows Vista was released.

A lot of people on MSDN asked this question, but couldn’t seem to get it to work either.  I just assumed that it couldn’t be done since nobody else couldn’t get it to work either. 

Luckily, I asked this question myself on one of the MSDN forums and a MSFT moderator was able to point me to this blog: http://asprosys.blogspot.com/2009/03/allow-service-to-interact-with-desktop.html

Thankfully, Stephen Martin was able to get the problem solved and even has some sample code to show you that it does work as it should.  It’s in C#, but you can always translate it to VB if you need to.  I personally used a converter found here: http://dotnetspider.com/codeconvert/Default.aspx.  The converter isn’t perfect, but it only had a few things that needed to be fixed.

One issue I had though was with running a .cmd file (I imagine the same issue would happen for .com/.bat files also).  For some reason, running the CreateProcessAsUser would show the command window then disappear.  My .cmd file was a long file name with spaces so I thought maybe that had something to do with it.  I included double quotes around my command string like this:  cmd.exe /c “C:\This Is a Long Path\command.cmd”  The .cmd file would not run. 

Scratching my head, I put the above string in the Windows Run and tried to run it.  It wouldn’t run here either… I then tried putting the .cmd file in the root of my C:\ and tried running it like this: cmd.exe /c “C:\command.cmd”  This ran fine.  I figured that since both CreateProcessAsUser and Windows Run were having the same issue, it was a good thing. 

After much playing around with the string and a lot of frustration, I tried the following: cmd.exe /c “”C:\This Is a Long Path\command.cmd”  This worked… I’m not too sure why the double quotes are needed twice before the long file name though…  This also works with the .cmd file that was in the root of my C:\ like this: cmd.exe /c “”C:\command.cmd”

WinForms/WPF Interop ElementHost Not Drawing The WPF Control!

<Edit>

It turns out it wasn’t externalizing the WPF control that solved the issue, but rather changing my build configuration to Release instead of Debug.  When I added the externalized assembly, I set the configuration to Release.  I’m not sure exactly why a debug build would cause this behavior…

</Edit>

<Edit 2>

It seems to work properly on Windows XP regardless of the build configuration.  Might be a Windows 7 thing…

</Edit 2>

I’ve been doing a lot of WPF work lately and a lot of it has been with WinForms interoperating with WPF.  Today I noticed some odd behavior when I tried to add a WPF control to a WinForms ElementHost object…

Usually I put the WPF control in a separate assembly, but today I thought I didn’t need to since it was just a very simple control.  Immediately I saw that the WPF control wouldn’t draw itself properly for some reason.  It would only draw itself sometimes, but if i clicked on the WPF control and somehow hit a Button or ComboBox, the control would show up.

I then decided to try and put the simple control in its own assembly and that solved the problem… It looks like there’s some issues with including a WPF control in a WinForms project directly, in my case anyway.  I’m using Visual Studio 2008 on Win7 x86 and if anybody else has this type of issue, try doing what I did to resolve the issue.