Category Archives: Microsoft Visual Studio

Fixing Error LNK2038 In a Visual Studio Project

While building a Visual Studio C++ project in Visual Studio 2022, I received this error while linking to a library:

Error LNK2038 mismatch detected for ‘_MSC_VER’: value ‘1800’ doesn’t match value ‘1900’ in MidiPlayer.obj MIDIPlayer E:\code\MIDIPlayer\wxmsw30ud_core.lib(dlgcmn.obj)

In case you’re not familiar with this error, Visual Studio wants to link with libraries that were built with the same version of Microsoft C (same toolset) as the code you’re compiling. In older versions of Visual Studio that meant that they had been built with the same version of Visual Studio, but now that versions aren’t as tightly-coupled to Visual Studio, it’s also possible that you can get this with libraries built with the same version of Visual Studio that you’re using.

The solution is to rebuild the library with the same MSC version as your project.

For reference, here are the different MSC, MSVC, and toolset versions:

Microsoft C 6.0: _MSC_VER == 600
Microsoft C/C++ 7.0: _MSC_VER == 700
Microsoft Visual C++ 1.0: _MSC_VER == 800
Microsoft Visual C++ 2.0: _MSC_VER == 900
Microsoft Visual C++ 4.0: _MSC_VER == 1000
Microsoft Visual C++ 4.1: _MSC_VER == 1010
Microsoft Visual C++ 4.2: _MSC_VER == 1020
Microsoft Visual C++ 5.0: _MSC_VER == 1100 (Visual Studio 97)
Microsoft Visual C++ 6.0: _MSC_VER == 1200 (Visual Studio 6.0)
Microsoft Visual C++ 7.0: _MSC_VER == 1300 (Visual Studio 2002)
Microsoft Visual C++ 7.1: _MSC_VER == 1310 (Visual Studio 2003)
Microsoft Visual C++ 8.0: _MSC_VER == 1400 (Visual Studio 2005 – v80)
Microsoft Visual C++ 9.0: _MSC_VER == 1500 (Visual Studio 2008 – v90)
Microsoft Visual C++ 10.0: _MSC_VER == 1600 (Visual Studio 2010 – v100)
Microsoft Visual C++ 11.0: _MSC_VER == 1700 (Visual Studio 2012 – v110)
Microsoft Visual C++ 12.0: _MSC_VER == 1800 (Visual Studio 2013 – v120)
Microsoft Visual C++ 14.0: _MSC_VER == 1900 (Visual Studio 2015 – v140)
Microsoft Visual C++ 14.1 – 14.16: _MSC_VER == 1910 – 1916 (Visual Studio 2017 – v141)
Microsoft Visual C++ 14.2 – 14.29: _MSC_VER == 1920 – 1929 (Visual Studio 2019 – v142)
Microsoft Visual C++ 14.3: _MSC_VER == 1930 (Visual Studio 2022 – v143)

It’s interesting that starting with Visual Studio version 2017, Microsoft started incrementing the MSC version with each “micro” build change.

Fixing Error MSB3843 in a Visual Studio Project

I updated my DrumPads code project to the latest version of Visual Studio 2022 and received this error when trying to build:

Error MSB3843 Project “DrumPads” targets platform “Windows”, but references SDK “Visual C++ 2015-2019 Runtime for Universal Windows Platform Apps v14.0” which targets platform “UAP”. C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets

I’m not sure whether the project was actually set to be UAP, or whether the migration set something to that.

Visual Studio Solution Explorer Showing "Universal Windows"

Solution Explorer Showing “Universal Windows”

To fix the error, I edited the DrumPads.vcxproj file manually. In the PropertyGroup sections for the build configurations I changed this:

<PropertyGroup Condition=”‘$(Configuration)|$(Platform)’==’Release|Win32′” Label=”Configuration”>
<ConfigurationType>Application</ConfigurationType>
<UseDebugLibraries>false</UseDebugLibraries>
<WholeProgramOptimization>true</WholeProgramOptimization>
<CharacterSet>Unicode</CharacterSet>
<PlatformToolset>v143</PlatformToolset
<WindowsAppContainer>true</WindowsAppContainer>
</PropertyGroup>

I removed the line <WindowsAppContainer>true</WindowsAppContainer> entries from all of the configurations and reloaded the project. It no longer showed up as “Universal Windows” and I was able to build without the error.

Solution Explorer Without "Universal Windows"

Solution Explorer Without “Universal Windows”

Updating a wxWidgets project for Visual Studio 2019

I recently resurrected a dormant code project and went through the process of converting a wxWidgets 3.0 project to wxWidgets 3.1 and updaing from Visual Studio 2010 to Visual Studio 2019.

Include Directories

Here are the things I had to change to make things build and run:

Change “Platform Toolset” to Visual Studio 2019 in General configuration properties.

Change include and library directories from wxWidgets 3.0.2 to 3.1.4 in VC++ Directories and update the include path for modern Visual Studio. The change to $(IncludePath) does a lot of magic things that will save a lot of trouble. Failure to update that will cause common includes like stdafx.h to be missing.

Change include from:
E:\lib\wxWidgets-3.0.2\include;$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSdkDir)include;$(FrameworkSDKDir)\include
to:
E:\lib\wxWidgets-3.1.4\include;$(IncludePath)

Code

The only code changes I had to make were to remove wxADJUST_MINSIZE anywhere it showed up.

Libraries

This is for the debug version of the project. Remove the “d” for libraries in the release version (i.e. wxbase31ud_core.lib => wxbase31u_core.lib).

These libraries showed up as missing:

comctl32.lib
rpcrt4.lib
uuid.lib
kernel32.lib

Adding C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\um\x86 to the linker directories fixed this.

msvcprtd.lib

Adding C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\lib\x86 to the linker directories fixed this.

ucrtd.lib

Adding C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\ucrt\x86 to the linker directories fixed this.

wxregexu.lib

Adding that to the library list fixed it.

I suspected there was something similar to $(IncludePath) I could add to the library paths to make those resolve, but I wasn’t sure. So I tried $(LibraryPath). And it worked. Magic!

So do that instead of adding those individual directories.

Change library path from:
E:\lib\wxWidgets-3.0.2\include;$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSdkDir)include;$(FrameworkSDKDir)\include
to:
E:\lib\wxWidgets-3.1.4\include;$(IncludePath)

Update all the libraries from wx 3.0 versions to wx 3.1 versions:

wxmsw30ud_core.lib => wxmsw31ud_core.lib
wxbase30ud.lib => wxbase31ud.lib
wxmsw30ud_adv.lib => wxmsw31ud_adv.lib
wxmsw30ud_html.lib => wxmsw31ud_html.lib
wxmsw30ud_xrc.lib => wxmsw31ud_xrc.lib
wxbase30ud_net.lib => wxbase31ud_net.lib
wxbase30ud_xml.lib => wxbase31ud_xml.lib

After these changes I was able to build and run my old project, which was originally written for wxWidgets 2.8 and then ported to wxWidgets 3.0.

Using MonoDevelop

I’ve almost always used both Windows and Linux, but I stopped using Windows a few months ago.  One of the things that only runs on a Windows machine is Visual Studio.  The Basternae code was compiled on a Windows machine and then uploaded to the Linux host.

Without access to that, it was time to try using MonoDevelop.

MonoDevelop
It was able to load the Visual Studio solution, with some exceptions:  The client WPF project didn’t load, nor did the abandoned Silverlight project.  I could probably install more packages to make WPF work, I’m not sure yet.

I noticed that the compiler works differently for some things, like terminal characters.  The ECHO_ON and ECHO_OFF sequences broke logging in, but some weird prompt formatting that’s been around for a while just fixed itself.  It will be interesting to see what other diffferences turn up.  Even though C# is supposed to work the same on all platforms, I suspect that it might work better when both the build and run machines have the same operating system.

Win32 Visual Styles

Nothing to do with Basternae, this is just a reminder to myself how to enable the visual styles for controls available in Windows XP and newer in a WIN32 project in Visual Studio 2010.  Had to do this at work and it’s a little tough to look up.

1. Edit Project settings.
2. Under Linker->Manifest File edit “Additional Manifest Dependencies” and add:

type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*';%(AdditionalManifestDependencies)

Suddenly Win32 controls will stop looking like they’re from Windows 3.1.  The modern control styles were introduced in ComCtl32.dll version 6, and Windows apps use version 5 by default unless you tell them not to.

C#: Compiling For 32-bit Systems on 64-bit

I recently upgraded from 32-bit Vista to 64-bit Windows 7.  I may be one of the only people who didn’t have anything bad to say about Vista.  For me it was a huge step up from Windows XP, but since I have 6GB of RAM in my system it’s a little silly to run a 32-bit OS.

I understand the differences between 32-bit and 64-bit C++ code behavior quite well, but I really haven’t spent any time digging into the differences between 32-bit and 64-bit .NET IL code.  Apparently it’s all quite a bit simpler in managed code.

Just right-click on a project, click properties, click on the build tab, and then select “x86” under “Platform Target”.

Visual Studio 2010

Three months ago I switched from Visual Studio 2008 to Visual Studio 2010 as my main development environment.  Functionally it’s the same as it’s always been, but there are two things about it I consider great improvements.

First, the UI:  It looks so a lot better and cleaner than earlier versions.  It’s not that older versions were ugly, but it has a cleaner look and is much easier on the eye.

Next, C++ Development:  For the last few versions of VS, C++ developers have pretty much been shafted — no real feature improvements for the most part with all the love going to C#.  C++ received a major boost, gaining just-in-time compilation and error-detection intellisense almost exactly like C# has always had.  It doesn’t sound like a big deal, but it is excellent for speeding up the code-compile-fix cycle.

Only a small portion of Basternae code is in C++, just the client and the Basternae 2 to 3 zone converter, but it is a lot more pleasant to write with Visual Studio 2010.

This project started on Visual Studio 2003, so now we’ve been through four versions.

ReSharper 4.5: It’s Finally Awesome

The two of you who have been following this blog regularly probably know that I’ve tried demos of JetBrains ReSharper versions 3 and 4 in the past.  The verdict was that they were pretty neat, but far too slow to be of any practical use.

Today I downloaded the trial version of ReSharper 4.5.  The big improvement they claim to have made is a significant speed increase.  After trying it out, I believe it.  They claim speed increases of about 25-40% depending on the type of project you’re working on, but that’s an understatement.  I’m using the same hardware I used for the previous test a year ago (yeah I need an upgrade, but that’s not something I care to address right now).   I haven’t used stopwatch tests, but it feels like ReSharper 4.5 is easily two to three times faster than ReSharper 4.0.

It’s now totally worth using — it has all of the benefits without any of the drawbacks the previous versions had.  Good work, JetBrains.

Accepted Into Microsoft BizSpark

Microsoft has this neat little program, BizSpark, that gives a company free access to pretty much all of their products for three years for a total of $100.  The idea is that if they can get startups hooked on Microsoft operating systems, databases, and development tools, then if the companies are still alive after three years they’ll become thriving, paying customers.

Seems like a smart idea to me.  After all, startups generally have to be run “on the cheap”, so most of them turn to Linux and open source solutions.  BizSpark is keeping Microsoft competitive, helping out startups, and is an all-around good thing.

So, my company, Zeta Centauri, Inc., was just accepted into the BizSpark program and I now have access to all these neat development tools, including Visual Studio 2008 Team Suite (which is $10k retail).  It’s still downloading, but I’m sure I’ll have to post about some of the bells and whistles that come with it.  I’ve never worked with anything above Visual Studio Professional.   With any luck these new and shiny tools will help me build something awesome.

Visual Studio Refactoring And Encapsulation

I love the refactoring support in MS Visual Studio.  It makes certain things like field encapsulation incredibly easy.

For instance, thanks to its origins in C, most of the Basternae 3 codebase doesn’t have encapsulation yet.  This means that there are tons of class member variables declared like this:

public string _keyword;

Setting the _keyword member variable to private and creating a property named Keyword with getters and setters that reference the _keyword variable would take about 30 seconds.

With Visual Studio it’s easier:  Just right-click on the variable and select “Encapsulate Field”.  It will come up with a reasonable property name and automatically generate the code and set the variable to private.

Pretty nice, but nothing to write home about.

But, here’s the magic:

All references to that variable in code are AUTOMATICALLY changed to refer to the property.  If that member variable was used in 50 different places, Visual Studio just saved you the trouble of making 50 different changes or doing a search-and-replace that may or may not get everything on the first try.

Of course, this doesn’t automatically update any XML files that have been saved using the old variable name.  To take care of that you can do one of two things.

1. Do a search and replace in every XML file that your class would have been serialized to and hope you didn’t miss one.
2. Use the XmlElementAttribute on your property to map the saved attributes to your new type:
[XmlElement(“_keyword”)]
public string Keyword
{

#2 is obviously safer and easier, especially since it doesn’t require changes to existing data.  Of course, your data files might be clearer to read if they used the exact property names, but do you want to go through the trouble?  Likely not.

Resharper 4.0

Last year I tried the Resharper 3 plugin for Visual Studio, and posted my thoughts on it:

http://basternae.org/blog/2007/07/26/jetbrains-resharper/

It was OK, but not all that special. It had potential, but wasn’t quite “there” yet.

I just finished trying out Resharper 4.0 and you could paste the Resharper 3.0 review in its place. It’s neat, but not so neat that it’s a ‘must have’ utility. The features added in the latest version really aren’t anything I find useful — I don’t refactor Visual Basic, don’t use LINQ, etc.

It does, however, appear to run a little faster than version 3.  That might just be the system I’m using it with, but the slowness is no longer an annoyance.

I’ll keep my eye on it. Maybe they’ll add something I can’t live without in a later version.

Taking The Visual Studio 2008 Plunge

Since VS2008 somewhat rudely decided that it would become the default application for all projects, including projects that were VS2005 projects (what exactly *is* the Visual Studio Version Selector good for, anyway?), I decided to try building Basternae with 2008.

It was actually a pretty painless process.

Something changes in every version of a compiler and 99% of the time something breaks, either due to deprecation, changes in the way warnings and errors are treated, or most often due to changes in dependencies and the way they are handled. In any project of significantly large size, you can expect errors when converting to a new version of Visual Studio.

It was no surprise when the project didn’t build. It was, however, a pleasant surprise. It found three bad cast operations that shouldn’t have been written in the first place, the sort of thing that VS2005 should have complained about but didn’t. After spending a few seconds fixing those, everything built fine with no problems.

Visual C++ projects are a different story. You see, I’m convinced that Microsoft hates Visual C++ and just wants it to shrivel up and die. As long as Visual Basic and Visual C# projects are healthy, it’s safe to release a new version of Visual Studio. This time it was a bit of DLL hell along the lines of missing MSVCP90D.DLL and MSVCP90.DLL errors when trying to run a newly-built executable. WTF? Weren’t those installed with Visual Studio? You mean we can build C++ projects but aren’t allowed to run them?

OK, OK, so maybe it was a missing runtime redistributable. That’s fair enough and something I could live with since that’s the way .NET works. So I download the Microsoft Visual C++ 2008 Redistributable and install it. Fail. Epic fail.

After an unsuccessful Google search (plenty of people with the problem but no clear solution) I went playing with some of the project settings. The final fix was setting “Generate Manifest” to “Yes” instead of “No” in the Linker->Manifest File section.

Free Copy of Vista Ultimate and Visual Studio 2008

Today was the Microsoft “launch event” for Visual Studio and Server 2008. I attended the local presentation and walked away with a free copy of Vista Ultimate and Visual Studio 2008. It was free to attend and I got $600 worth of software out of the deal. How can you beat that? Sure the presentations weren’t very relevant to the types of development I do (all they talked about were database-driven development, MS Office add-in development, and ASP.NET web development, all of which I don’t have any involvement in.)

I may or may not switch development of Basternae 3 to VS2008 right away and probably won’t start using Vista until my next PC upgrade, but it still feels nice to get free stuff.

JetBrains ReSharper

I just finished a trial of JetBrains ReSharper 3.0, an add-on for Visual Studio 2005 designed for code analysis and refactoring.

ReSharper’s main feature is automatic code analysis. When you open a code file, it will scan for and higlight errors in your code and show an error count and error locations on the sidebar. It also goes a step further than the compiler by highlighting warnings and making suggestions for improving code.

For many errors, it will pop up a lightbulb icon if it knows how to fix the problem. If you click this icon, it will give you a menu that will let you perform a quick-fix.

ReSharper is smart enough to warn about places where a NullReferenceException could occur and overrides intellisense with its own, more thorough version. It gives more parameter information, shows more class info, and takes intellisense to the next level in general.

Visual Studio’s refactoring options are a neat addition, but not overwhelmingly useful. ReSharper extends them quite a bit to add a lot more functionality. I never really made much use of ReSharper’s refactorings since I prefer to change things by hand.

ReSharper has quite a few features that I couldn’t imagine ever using, such as code generation, code templates, and build script editing.

Although it add a lot of features and functionality to Visual Studio, in a project of any significant size (such as the 116k-line Basternae codebase) it causes a drastic slowdown, rendering my development machine nearly unusable at times, especially when code analysis is grinding away on a large code file. It’s true that the codebase I’m working on isn’t optimal (huge classes, bloated files, plenty of errors, etc), but that’s why I’m working on it in the first place — to fix all of that.

It’s an ambitious tool, but perhaps it’s trying to do too much. Maybe future versions will be faster, but right now it doesn’t add enough value to the development process to justify the $149 price tag.

If JetBrains removed everything but the code analysis functions for a “lite” version that sold for $49 I’d buy it in a heartbeat, but as it is now ReSharper doesn’t speed up my development process more than it slows it down. I’ll look at the 4.0 version when it comes out, but 3.0 isn’t for me.

Visual Studio Becomes More Responsive

I mentioned in an earlier post that Visual Studio 2005 was gradually becoming more responsive as the error count decreased.

On my system, which is a Pentium D 2.66 GHz with 1GB of RAM, it starts becoming usable again at about 22,000 errors (we’re at 22,267 now).  That’s where the “type-a-character-and-wait” transitions into using the application in realtime.

One thing to keep in mind is that I have a trial installation of ReSharper (which I’ll post about once I’ve had more chance to evaluate), which slows things down considerably due to constant recompiling to find errors in realtime and excessive intellisense-ing above and beyond that which Visual Studio does.  Without Resharper I think I would have noticed responsiveness a bit earlier, but for now I have to say that 22,000 errors should be considered the upper limit of usability in a system like mine.

With more RAM it would probably be a bit better, and at this point it probably makes sense to upgrade to 2GB (RAM’s gone down quite a bit recently, probably due to Vista finally starting to sell).  I’ll have to add that to my grocery list.

VS2005 Regular Expression Search Rules!

One of the things I had to do to eliminate a few thousand bugs as part of this C++ to C# conversion is replace the text transmission functions.

Nevermind how they work internally, the important thing for the sake of the current conversion is that they look completely different.

The old functions looked something like:

send_to_char( “Words.\n\r”, ch );

While the new functions are supposed to look like:

ch.SendText( “Words.” );

With around 4000 or so calls to that function, it would be a dauntingly huge project to retype every reference to send_to_char. Because it’s a bit more complicated than a simple word replace, we would be hosed if not for Visual Studio 2005’s regular expression search and replace.

If you Google regular expression search-and-replace, most likely you’ll come up with a lot of people complaining about it. Ignore them — those people are whiny idiots. It is easily one of the most useful things ever added to Visual Studio and it takes about 10-15 minutes to get the hang of.

To make the above change, all I had to do was do a search for:

send_to_char[(] {:q}, {:i} [)];

And replace it with:

\2.SendText( \1 );

As a basic explanation:

1. Anything in [] brackets means “any of these characters”. I had to bracket the parenthesis to keep the parser from evaluating them as an expression.
2. Anything in {} brackets means that it’s assigned an “expression tag”. It’s the equivalent of the scripting language act of assigning it to %0, %1, etc and they’re numbered in the order they are found.
3. :q means match a “quoted expression”.
4. :i means match a C++/C# identifier (i.e. a variable name).
5. \1 means “insert the first tagged expression”. \2 inserts the second, etc.

This is enough to get the basic idea going, and it works like a charm, provided the functions are spaced EXACTLY as indicated. If you have something like (notice spaces):

send_to_char(“Something” , ch );

It will not work. In any codebase that has had more than one person’s fingers in it, you’ll have inconsistent spacing. Some people will put spaces before/after every variable, some won’t, and some will be mixed. That’s why we have to set it to ignore spaces anywhere they will be a concern. We do this by inserting [ ]* which means “match anywhere from 0 to infinity spaces”. The search expression now looks like:

send_to_char[(][ ]*{:q},[ ]*{:i}[ ]*[)];

And now that I’ve figured out how to use regular expressions, all of the references to the Diku send_to_char function have been replaced with our shiny new code.

The error count is now down to 24,414.

Visual Studio 2005

I’ve been using Visual Studio .Net 2003 for a long time. I’ve finally upgraded to 2005, and some of the changes are interesting.

One of the things I’ve been doing is converting a lot of the c-string functions to STL std::string. It turns out that the old string functions I’m gradually eliminating have been deprecated:

_snprintf: “This function or variable may be unsafe. Consider using _snprintf_s instead.”
strncat: “This function or variable may be unsafe. Consider using strncat_s instead.”
stricmp: “The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _stricmp”
fopen: “This function or variable may be unsafe. Consider using fopen_s instead.”
strncpy: “This function or variable may be unsafe. Considre using strncpy_s instead.”

I will gladly avoid using those functions. I hate them.