How to avoid that problem of never being 'up to date'

by Michael S. Kaplan, published on 2008/02/18 10:16 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/02/18/7748433.aspx


I am never the type of superior elitist code snob who feels above people who improve on the things that I do. Or have done.

And even if something is no longer officially supported by Microsoft, I am not the sort to just ignore people who are still trying to work productively with code that I have produced in the past....

Like the other day over in the microsoft.public.platformsdk.mslayerforunicode newsgroup, Igor Solodovnikov wrote:

To build your project with MSLU it is recommended (http://msdn.microsoft.com/msdnmag/issues/01/10/MSLU/default.aspx) to include following in the beginning of project's link list:

/nod:kernel32.lib /nod:advapi32.lib /nod:user32.lib /nod:gdi32.lib /nod:shell32.lib /nod:comdlg32.lib /nod:version.lib /nod:mpr.lib /nod:rasapi32.lib /nod:winmm.lib /nod:winspool.lib /nod:vfw32.lib /nod:secur32.lib /nod:oleacc.lib /nod:oledlg.lib /nod:sensapi.lib
unicows.lib
kernel32.lib advapi32.lib user32.lib gdi32.lib shell32.lib comdlg32.lib version.lib mpr.lib rasapi32.lib winmm.lib winspool.lib vfw32.lib secur32.lib oleacc.lib oledlg.lib sensapi.lib
<you own libraries>

There is problem when you try to use MSLU in Visual Studio 2005: if you add recommended list of nod's and libraries to "Linker::Input::Additional dependencies" option in project's property ages then every time you will start debug session using "Debug->Start Debugging" or build your project using "Build->Build myprj" you will get something like this:

    ------ Build started: Project: myprj, Configuration: Debug Win32 ------
    Linking...
    Embedding manifest...
    Build Time 0:10
    Build log was saved at "
file://c:\myprj\Debug\BuildLog.htm"
    myprj - 0 error(s), 0 warning(s)
    ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========


So i want to say that your project will never be in up-to-date state. Interestingly enough that this problem does not appear if you build problematic solution from command line using msbuild tool:

    msbuild mysolution.sln /p:Configuration=UDebug
 
This means that building solution from command line is slightly differs from building from IDE.

There is workaround for this problem:
1. Include the following in "Linker::Input::Ignore Specific Library" option:
    kernel32.lib advapi32.lib user32.lib gdi32.lib shell32.lib comdlg32.lib version.lib mpr.lib rasapi32.lib winmm.lib winspool.lib vfw32.lib secur32.lib oleacc.lib oledlg.lib sensapi.lib
2. Include the following in "Linker::Input::Additional dependencies" option:
    unicows.lib
    kernel32.lib advapi32.lib user32.lib gdi32.lib shell32.lib comdlg32.lib version.lib mpr.lib rasapi32.lib winmm.lib winspool.lib vfw32.lib secur32.lib oleacc.lib oledlg.lib sensapi.lib
    <you own libraries>


Using such settings your project will be up-to-date when it should.

That link at the beginning of what he wrote is to the article Cathy Wissink and I wrote in October 2001 (Develop Unicode Applications for Windows 9x Platforms with the Microsoft Layer for Unicode) and although it has obviously been many years and I can forget details in co-author situations as to who added what information, I am pretty sure the linker settings were part of what I contributed (with help from others behind the scenes, of course!).

Anyway, like I said I have no problem with people suggesting enhancements to what I do.

The only advantage that the original plan has over Igor's enhancement is that it is slightly easier to use one setting than two, but the benefit pales wshen compared not forcing rebuilds even when no rebuild is needed. Therefore I am happy to agree that this is a better idea.

So if you are using MSLU and you build it in Visual Studio, feel free to avail yourself of this advice!

 

This post brought to you by(U+ff55, aka FULLWIDTH LATIN SMALL LETTER U)


no comments

go to newer or older post, or back to index or month or day