Rss Feed
Tweeter button
Facebook button
Technorati button
Reddit button
Myspace button
Linkedin button
Webonews button
Delicious button
Digg button
Flickr button
Stumbleupon button
Newsvine button

Posts tagged: Visual Studio

Cleaning up Visual Studio

By , March 19, 2018 12:33 pm

Why would you ever need a tool to clean up Visual Studio? Doesn’t Visual Studio have a built in “clean” mode that cleans your build directories?

Yes, it does, but that only cleans the file created by compiling and linking your software. Visual Studio also creates other files. How do you get rid of those files? Look them up, then search for them manually? That’s going to be time consuming.

Why would you even want to delete these extra files?

We’ve also seen Visual Studio crash from time to time. Sometimes it’s a plugin or extension gone astray, but other times it’s when you do something harmless like load a project or workspace or solution. What we found was that in many cases, just deleting the extra files would prevent future crashes.

So we wrote Visual Studio Project Cleaner to do that. The first version of the tool was written to work with Visual Studio 6, but we’ve updated it to also cleanup so of the files created by the newer versions of Visual Studio, Visual Lint and Visual Studio Project Fixer.

What type of file can we clean?

  • aps. Last Resource editor state.
  • bak. Backup file.
  • bsc. Source browser database.
  • dbg. Debugging information.
  • exp. Exports file.
  • idb. Minimum rebuild linker file.
  • ilk. Incremental linker file.
  • ipch. Incremental precompiled header file.
  • lastbuildstate. Build helper.
  • log. Build log.
  • map. Linker MAP file.
  • ncb. Intellisense database.
  • obj. Object file.
  • opt. Visual Studio options.
  • pch. Pre-compiled header file.
  • res. Compiled resource script.
  • sbr. Source browser information.
  • sdf. Intellisense database.
  • tlog. Depdenency file information.

We can also clean the following file types (these are disabled by default).

  • lib. Library file.
  • dll. Dynamic Link Library.
  • exe. Executable.
  • pdb. Program database.
  • old. Visual Studio upgrade files.
  • Visual Lint files in .visualint directories.
  • Visual Studio Project Fixer backup files (*.vcxproj-YYY-MM-DD-HH-MM-SS)

Clean your Visual Studio

We’ve been using Visual Studio Project Cleaner for years to clean unwanted files. It turns a tedious job into a simple and easy job.

Clean your files today with Visual Studio Project Cleaner.


Improving how we build projects and solutions

By , March 12, 2018 12:01 pm

The problem with Solutions

If you’re working with just one solution and the projects it contains Microsoft Visual Studio is a good tool for managing the builds. Except that it won’t necessarily build the projects in the right order, forcing you to make multiple build passes to get a built solution.

But what if you’re working with many solutions?

What if some of the projects in the solutions have identical project names, even though they are different projects? You can’t merge these into one mega solution so that you can build everything at once because the project names will clash.

Another problem with solutions is that the projects in the solution do not necessarily get built in the optimum order. A project that depends on another project may be built before that project dependency is satisfied. This forces you to build the solution multiple times until all dependencies are satisfied.

What if there was a better way to manage your builds? What if there was a better way to automate your builds?

Born from a real need

At Software Verify we have a code base of several million lines of C++, plus some C, assembler and C#. Looking at the Visual Studio Project Builder display I can see we have 28 solutions, with 217 projects, giving us a total of 962 different project configurations to complete a build. (The actual number is higher than this because it doesn’t include the legacy support solution and projects for Visual Studio 2002, because that can’t be installed on a 64 bit machine.).

This large number of projects and solutions includes every version of Visual Studio from Visual Studio 2017 to Visual Studio 6.

We needed to have a build tool that would allow us to reliably build a project, or solution, or a specific configuration of a project, regardless of version of Visual Studio or programming language.

All this would be done with one simple to use software tool that could be used interactively with a GUI or from the command line. The tool would provide visual feedback so that you could tell from 50 feet if the build was going pear shaped. The tool would also provide notifications so that you could forget about it and go do something else instead.

Visual Studio Project Builder

I’ve seen various solutions to this problem, lots of scripts, batch files, programs interacting. It works, kind of, but it’s all a bit of a mess, held together with string and duct tape in the best “make it work” seat of the pants “we haven’t got enough time” developer fashion.

That isn’t what I wanted. We’d already finished Visual Studio Project Fixer and I was very pleased with the results from that. I wanted the same “one tool” approach. We had the requirements, we knew what we needed to be able to build. We knew we had a decent test case (build our own tools) and we knew what a good tool would look like. As simple as possible.

That’s how Visual Studio Project Builder was born.

The basic capabilities are:

  • Automatically discover solutions and projects.
  • Optimise the build order.
  • Build, rebuild, clean project for any Visual Studio version from 2017 to 6.
  • Build individual project configurations, or variations based on project, solution and configuration.
  • Easily identify warnings and errors.
  • Easily filter warnings and errors.
  • Interactive GUI with real time build progress updating.
  • Can be run from a command line if desired.
  • Works on any Windows OS from Windows 10 through Windows XP.

A simple user interface

When performing a full build, full rebuild or full clean, a progress dialog is displayed, allowing the progress of the build to assessed at a glance, but with extra detail if you want it. You can tell from the colours on this dialog if a build is good, or bad, or has warnings, from 50 feet.

Behind the progress dialog is the main display, showing the status of every project configuration that can be built. Colours indicate status (good, warning, compiler error, linker error). A context menu provides access to options related to that project configuration, project or solution. For example:

  • Build all projects named “stubNonMFC” that have the configuration “Win32|Debug”.
  • Rebuild all projects that have the configuration “Win32|Release”.
  • Rebuild all projects in this solution that have the configuration “Win32|Release”.
  • Clean all projects named “tabserv”.
  • View build logfile.
  • View build command line passed to Visual Studio.

Some of the build options from the context menu cannot be done with Visual Studio, except by manual intervention for each project. When you span this across many solutions and projects this becomes very powerful and an incredible time saver.

Build notifications

Software developers perform a mentally taxing job. The last thing you want to add to their list is “Is the build done yet?”. To remedy this problem we have provided several (optional) notification methods:

  • Email when build is complete.
  • Text message when build is complete. Uses Twilio.
  • Speech message when build is complete.

My favourite is the last one. I can go and do something else, read a book, investigate a bug, work on something else, talk to someone, and when the build is done my computer talks to me: “Build Complete, Success”, or “Build Failure. 3 Errors”.

The email and text message notifications are intended for use when you are out of range of the computer talking to you.

We have delayed implementing carrier pigeon functionality until there is a proven market for it.

Does this compete with existing build solutions?

Does this compete with existing build solutions such as IncrediBuild?

No. Incredibuild speeds up builds of projects and solutions by distributing them on your local network.

Visual Studio Project Builder is all about getting projects built, in the right order, even though many toolsets may be in use. It all happens on the same machine. We’re hoping that Visual Studio Project Builder can work with build accelerators like IncrediBuild to speed things up.

Build your Visual Studio Projects

We’ve been using Visual Studio Project Builder in house for some time. We thought it was about time everyone else got a chance to use it. We’re making this available for free. Learn more about Visual Studio Project Builder.


Fixing Visual Studio project problems

By , March 5, 2018 2:51 pm

The productivity sink

Visual Studio is a very productive development environment. However, you can get Visual Studio into a state (for C++ and C developers, at least) where the compile and link both succeed, but when you go to run the executable Visual Studio annoyingly tells you that the build is out of date and would you like to build it?

This is a very frustrating experience. You go around and around in circles trying to work out what is wrong with the project that is causing this warning message to be displayed.

After some head scratching you’ll Google it and find solutions on numerous websites that tell you to do this, or that, or the other. The advice on some sites is consistent with the advice on other sites, some advice is not consistent. Then you find that some advice is for one version of Visual Studio, but you need to do something differently for a different version of Visual Studio.

It’s a mess. But you work out what you need to do, set about it and after tweaking a registry setting, running a tool to grab the output from OutputDebugString (or writing one if you couldn’t find a tool!), you now know which file is causing Visual Studio to tell you the build is out of date. Great!

Er, not so fast. The problem with this is Visual Studio only tells you about the first file that causes it to need to be rebuilt. Any other files aren’t listed, so you have to make the change then repeat the whole cycle. Slow!

“Crikey, that was a lot of effort, I hope that doesn’t happen again”, you think, or perhaps something a bit less polite. And then you remember you’ve got 10 more projects that behave like this, but you’d been ignoring that for a long time. But now you know how to fix it, but you can’t imagine putting in the effort for those 10 projects.

That was the situation we were in, except that just about every project we had (over 200 projects) had this problem. After tackling just one project I knew we had a choice:

  • Ignore the warnings.
  • Fix the warnings manually. Very slow. Lots of typing. Boring. Morale killer.
  • Find a way to automate the fixing of these problems.

Our engineering needs drove the decision.

Visual Studio Project Fixer

We decided to write a tool to make the hard bits of the above easy and to automatically discover what was wrong with a project file, then allow the user to choose which items to fix and which to leave alone. Plus an automatic mode that just fixes everything for you.

Things that can affect a project file are:

  • Missing files. The file exists on disk, but is not specified in the project.
  • Incorrect files. The file exists on disk, but not in the location specified in the project
  • Nonexistent files. The file doesn’t exist on disk, but is specified in the project.
  • Obsolete files. Files from older versions of Visual Studio.
  • .tlog files. Visual Studio file dependency files.

Some examples…

Missing file. You have a class defined in class.h and implemented in class.cpp. Only class.cpp is listed in the project file.

Incorrect file. A file is listed in the project as ..\svlCommonUI\class.h but is actually located at ..\svlCommon\class.h.

Nonexistent file. A resource file is specified that doesn’t exist. .\images\nonexistent.bmp.

Obsolete file. An old format help file from an early version of Visual Studio, carried over in Visual Studio project conversion.

A simple user interface

The image above shows the user interface after a scan of many projects has been performed. The summary display is shown, which lists an overview of the state of the projects and provides an option to automatically fix all the projects. If you click an individual project, the display changes to provided detailed information about that project.

There are four ways of scanning projects, providing for maximum flexibility in automating fixes or manually choosing each fix to apply.

  • Open a project.
  • Open a solution.
  • Open all projects in a directory (and sub-directories).
  • Open all projects in solutions in a directory (and sub-directories).

Having scanned some projects you can examine the results and choose to fix individual projects, or to fix all the projects that need fixing.

The default settings are to backup all project files before modifying them.

Diagnostic Information

It is possible that even with all the information provided by Visual Studio Project Fixer you may still wish to view the output from Visual Studio. Visual Studio 2015 and 2017 provide an option to show you this information. However for Visual Studio 2010, 2012 and 2013 you can enable diagnostic information to be sent via OutputDebugString(). This means that Visual Studio Project Fixer can intercept this information. All you need to do is enable it (from the Edit menu).

Then every time Visual Studio checks the status of a build, it’s output can be seen on the Visual Studio OutputDebugString tab.

Fix your Visual Studio Projects

We’ve been using Visual Studio Project Fixer in house for some time. We thought it was about time everyone else got a chance to use it. We’re making this available for free. Learn more about Visual Studio Project Fixer.


Changes to how we build our software

By , January 4, 2015 8:25 pm

Starting with our first software release of 2015, we will start shipping software that uses the Visual Studio 2010 C runtime and MFC libraries. The purpose of this article is to explain why we’re making this change and how this will affect users of our software.

Some of our past choices have been about technology and some about ease of doing the work. If the operating system or development environment fights you, you are less likely to use it.

Compiler History

When we started the company the current version of Visual Studio was Visual Studio 6.0. So naturally our software shipped with C runtime and MFC libraries for Visual Studio 6.0.

We didn’t really like the direction the Visual Studio team went in with subsequent releases,in particular with some subtle changes to the debugger that, it seems, many people have never noticed. These changes removed a particular feature from the debugger that we find very useful (drag an address to the disassembly view and automatically get the disassembly displayed – the workaround to do this in current versions of Visual Studio is clumsy, error prone and occasionally fails). Because of this we continued using Visual Studio 6.0 to build our software. Anything requiring support for more recent versions of Visual Studio would be built using that version of Visual Studio (library stubs, Visual Studio editor support, etc).

When we started exploring 64 bit support we started with Visual Studio 2008 because that was the current toolset at the time. Our 64 bit tools ship with the Visual Studio 2008 C runtime and MFC libraries.

For our .Net tools we’d be using Visual Studio 6.0 for the GUI, but Visual Studio 2010 (or 2012) for the profiler backend.

This resulted in our routinely using multiple versions of Visual Studio to do development.

OS History

Historically we have supported all operating systems from Windows NT 4 onwards. We have always wanted to support our customers using Windows NT 4 and Windows 2000. Many people using Windows embedded are still on old versions of Windows.

We made the rather unusual decision to develop on Windows XP x64 but to test on Windows 7 and Windows 8. This decision was mainly due to UX blunders Microsoft had made with the Start Menu on both Windows 7 (no fly out start menu) and 8 (no start menu!), and also to the file search functionality which is very easy to use on XP x64 and very hard to use from Windows Vista onwards.

These may seem like trivial things but we use file search a lot and often the Visual Studio file search is not the tool you need. Simply put we found XP much, much easier to be productive with compared to anything that came after.

Reason for change

Since April 2014, Microsoft no longer supports Windows XP. From a security standpoint this isn’t good. For us, or for you (if we get compromised, how can you rely on us?). As such we had to move away from Windows XP x64 whether we wanted to or not. We’ve written some tools to allow us to do fast easy searching without needing to go near the UX disaster that is the current version of Windows search. The removes one of our main objections to working on Windows 7 or Windows 8 on a daily basis.

We also tested a lot of start menu replacements. We finally settled on Classic Shell as this not only provides a very useful start menu on Windows 8 but also allows you to have a proper fly out menu (like XP) rather than the cramped and very awkward to use compressed menu you get with Windows Vista/7 (no wonder Microsoft’s UX metrics showed start menu use was down – they’d made it too hard to use).

So that’s the two UX reasons out of the way, what about the software?

We would also like to take the software tools in new directions – to support .Net alongside C++ rather than in separate tools. This can be done using our current arrangement but it’s harder than necessary. In particular it makes automating our builds harder. Visual Studio 2010 is a lot easier to control from the command line that Visual Studio 6.0. So moving to one Visual Studio for this is a major bonus. Also, debugging software built using multiple different versions of Visual Studio, some of which can’t read debug info from other versions of Visual Studio, that is horrible.

We noticed that no one has discussed Windows NT 4 or Windows 2000 with us for quite some time so we decided to drop support for Windows NT 4 and Windows 2000. Removing this constraint meant we could move to the Visual Studio 2010 runtime and thus use one main version of Visual Studio to do most development work.

The reasons the Visual Studio 2010 runtime is important is because this is the most recent runtime that supports Windows XP and many people are still using Window XP.


An unfortunate consequence of this change to Visual Studio 2010 runtimes is that if you are using more than one of our 32 bit tools or more than one of our 64 bit tools then you will need to install new versions for all of the 32 bit tools (or all of the 64 bit tools). The reason for this is due to DLL dependencies and memory allocated by DLLs all needing to come from the same allocator. Mixing VS 2010 built DLLs with VS 2008 built DLLs or VS 6 built DLLs will give unspecified results.

We realise this is inconvenient and certainly not ideal. We won’t be changing the runtime we use again until none of our customers need support for Windows XP. We anticipate people using XP for many years into the future (based on comments made to us by customers).

The Future

We aim to roll all the functionality of our .Net tools into our C++ tools. C++ Coverage Validator will be able to collect coverage data for .Net code, C++ Memory Validator will be able to collect and analyse .Net memory data, C++ Performance Validator will be able to profile .Net code. The .Net specific tools will then be phased out.

If you are using our .Net tools, you will still be supported – we’ll move your .Net licences to the C++ licences where you will get the .Net data previously provided by the .Net tools.

If you are using our C++ tools, you will get additional .Net data in the tool.

The intention is that the tools will simply get better. We aren’t going to damage the C++ side of the tools to provide the .Net support. I mention this because we’ve had some questions from customers asking about this (having seen what some of our competitors did when they decided to support .Net).

Visual Studio

We will continue to support every version of Visual Studio from Visual Studio 6 through Visual Studio 2013 (and what comes after it, Visual Studio 2014 CTP, now renamed Visual Studio 2015 CTP) and future versions.

Windows NT 4, Windows 2000 support

If you need support for Windows NT 4 or Windows 2000, please contact us. We will be able to support these operating systems, but only via a special build facility.


Visual Studio 2014 CTP

By , August 12, 2014 3:54 pm

A few months ago Microsoft released the Community Technology Preview of Visual Studio 2014, also known as Visual Studio 2014 CTP.


Because this is a community technology preview it only runs on Windows 8. Microsoft recommend that you do not install this on any machine that is important to you. This caused me some frustration. I had any number of Windows 7 machines I could have put this on, but Windows 8 machines – the ones we have are being used for important tasks. This meant creating a VM I could use. I spent probably the best part of 2 weeks futzing around before I finally got a Windows 8 VM working that would succeed in installing Visual Studio 2014 CTP. I tried creating virtual machines from other virtual machines, creating virtual machines from existing Windows 8 machines. All failed.

The only thing that succeeded was with a brand new Windows 8 install from DVD followed by installing Visual Studio 2014 CTP. And even then for the install to succeed it had to be a web install. The download and .iso, burn it and install from that always failed (just like for 2012 and 2013).

As with 2012 and 2013 before the install process is horrible and un-informative. Gone are the days of an install dialog that tells you what it’s doing and that has a useful progress bar. Now we have these “I’m doing something bars” which tell you nothing about how far through you are and only serve to tell you that the thread that is running the animation hasn’t crashed. I hate these things. I really do. It’s an awful user experience.

The install dialog does tell you what it’s doing at each stage – but nothing while it’s doing it, so you have no idea it’s progressing or has hung. I’ve had so many failures installing 2012, 2013 and 2014 that I don’t trust the installer. And trying to uninstall any of them, that always fails. I know 2014 CTP is a preview but 2012 and 2013, they are released software.

User experience

This is the next version of Visual Studio, following on from 2012 and 2013 and continuing with the same theme, that very toned down, hard to use, monotone look, although you can choose the “blue” theme. Why they do this I have no idea. Apple excel at UX and at one time it appeared Microsoft did, but now it’s make everything as hard to use as possible. Colours on icons add information, so don’t take that away! (*) They seem to have got the message on mixed case text though. ALL CAPS is gone.

* I gave up with my Windows Phone because of the icons, it was a great phone except for that crucial bit of UX – I was continually guessing at what the icons meant, I could never be sure – no ease of use.

Version Number

The version number for Visual Studio 2014 CTP is 14.0. This is a change to the natural sequence which would have been 13.0.

This means the C Runtime and MFC dlls end with 140.dll, 140u.dll, 140ud.dll, etc.

What’s new? C Runtime DLL

If you’re a C/C++ developer the big news is that msvcrNNN.dll is gone. The old naming convention for the Microsoft C runtime has been done away with.

The new C runtime DLL is appcrt140.dll (and appcrt140d.dll for debug builds).

Other DLLs that ship with it are desktopcrt140.dll, msvcp140.dll, vccorlib140.dll and vcruntime140.dll

Full list of candidate redist DLLs:

  • appcrt140.dll
  • desktopcrt140.dll
  • msvcp140.dll
  • vccrlib140.dll
  • vcruntime140.dll
  • vcamp140.dll
  • mfc140u.dll
  • mfcm140u.dll
  • mfc140chs.dll
  • mfc140cht.dll
  • mfc140deu.dll
  • mfc140esn.dll
  • mfc140fra.dll
  • mfc140ita.dll
  • mfc140jpn.dll
  • mfc140kor.dll
  • mfc140rus.dll
  • vcomp140.dll

What’s new? DTE

If part of your work involves getting the Visual Studio IDE to do anything you want, such as opening source files for editing then you’ll be working with the Visual Studio DTE. The new DTE number skips a version and jumps from 12 to 14. So you’ll want:


Debug memory guard structure, x86

The debug implementation of the C runtime heap uses a linked list with helpful debug information and two guard regions before the debug header and after the allocated data. The helpful debug information sits in the debug header with the linked list pointers. Beginning with the introduction of the 64 bit support this header was modified to swap two data members (size and blockUse) around to improve the memory usage for 64 bit systems (alignment on 8 byte boundaries). This was handled via conditional compilation so that the data members remained in the original order for use on 32 bit systems.

That conditional compilation element has gone! This now means code that inspects the debug heap for 32 bit systems needs to know if it’s working with a heap layout that pre dates Visual Studio 2014 CTP or is from Visual Studio 2014 CTP. Failure to understand this heap layout change will likely result in code that inspects the heap and reports incorrect block sizes and/or corrupt data blocks when the data blocks are not corrupt.

This is a serious change. It’s also an obvious step to take. Visual Studio 2014 CTP cannot read debug symbols created with Visual Studio 6. This layout change also puts paid to debug heap support from that era. Along with dropping (or trying to drop!) support for Windows XP this is another sign that although many people are still using older operating systems (*) (and compilers) Microsoft is sending a sign that they really do want to drop the older way of doing things.

(*) Every now and then we field support questions asking if we still support Windows 2000 (yes), Windows XP Embedded (yes) or Windows CE (no).

Low level detail

The compiler continues to create ever more optimized code. As with some of the Windows 7 service pack releases we’ve noticed some optimized code sequences that do things differently to before. Visual Studio 2014 CTP doesn’t ship with source or symbols to APPCRT140.DLL (although you can get the latter from Microsoft’s symbol servers) so it’s hard to tell what’s going on inside the new C Runtime. But it’s clear it’s a new architecture and way of doing things. Many functions that once would have been called by linking to them and the call being redirected through the Import Address Table are now passed to a lookup helper function that does some sort of encryption, calls GetProcAddress, does more encryption and then passes the function back to be called. Why do I mention encryption? Because the function names hint at that. It’s quite a change from how things used to be done. Why it’s being done I can’t say, we don’t have the source to examine and I haven’t tried to reverse engineer the functions. These are just comments about things I noticed while I was investigating some unexpected behaviour as we were adding support for Visual Studio 2014 CTP to our C++ tools.

Updated – A day later!

Just after we published this article James McNellis from the Microsoft Visual C++ Team Blog contacted us to let us know a few things.

  • Apparently source code for the C Runtime is available but the reason you don’t see it in the debugger is because the symbols files on Microsoft’s symbol servers have been stripped – they only have function names but not filenames and no line numbers.
  • A solution to this is to build your C/C++ application linked statically to the C Runtime. This gives you symbols to examine the C Runtime. We didn’t notice this because the only occasions when we ran into any problems with our ports was working with code dynamically linked to the C Runtime.
  • Two articles detailing why the changes have been made have been posted to the Visual C++ Team Blog. These articles are worth a read and show that their thinking is looking forward many years into the future, mainly with an eye on improving things for developers and security issues. These articles are:

When you understand the refactoring and the desire for a wider platform support you can understand the reason for looking up functions by GetProcAddress() and calling the result rather than linking to them. Thanks to James for reaching out and letting us know their thinking.

From the above articles the standout thing for me is that most people will (for the short term at least) want to compile with _CRT_STDIO_LEGACY_WIDE_SPECIFIERS defined so that <tchar.h> continues to provide the string functions your code expects and not the C99 standard implemented in Visual Studio 2014.


What will Visual Studio 2035 be able to do?

By , March 17, 2010 12:53 pm

Will Visual Studio 2035 exist? Will we design and write software the same way in the future?

Read Bruce Eckel’s thought provoking article about “Programming in the mid future”.


Panorama Theme by Themocracy