locked
VS Project Linker Configuration: Can macros be used in "Additional Library Directories:" field? RRS feed

  • Question

  • I need to define Project Linker Configuration "Additional Library Directories" field using macros. Like:

    Additional Library Directories: ..\lib$(PlatformArchitecture)($PlatformToolset)

    It appears it won't accept it.

    Is there a way to do this?


    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com

    Wednesday, April 10, 2019 12:36 PM

Answers

  • I would say that is a Visual Studio 2015 IDE bug.

    It works just fine in 2017 and 2019.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Marked as answer by hector santos Thursday, April 11, 2019 3:10 PM
    Thursday, April 11, 2019 4:09 AM

All replies

  • I need to define Project Linker Configuration "Additional Library Directories" field using macros. Like:
    Additional Library Directories: ..\lib$(PlatformArchitecture)($PlatformToolset)

    It appears it won't accept it.

    Are you just missing a \ ?

    ..\lib\$(...

    Dave

    Wednesday, April 10, 2019 4:21 PM
  • No, the editor has a MACRO button to explore but no "INSERT" button.  After manually editing the field and hitting OK, it appears to ignore it and restores to the just ..\lib.

    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com

    Thursday, April 11, 2019 1:40 AM
  • I would say that is a Visual Studio 2015 IDE bug.

    It works just fine in 2017 and 2019.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Marked as answer by hector santos Thursday, April 11, 2019 3:10 PM
    Thursday, April 11, 2019 4:09 AM
  • Ok, thanks for the verification.  Bug or "New Feature."   I may have to go to VS2017 before going to VS2019, but right now I need to get this all worked with the current system VS2015.  Essentially, I am creating 4 release configurations for:

    - 32/64 bit
    - V140 and V140_XP toolset

    Until I understand it further of a new massive production layout (simpler before with just 32 bit V140_XP), I need to keep the lib files separated for the proper "non-conflict" binding and also for distribution, setup creations and 3rd party SDK.  I am doing the same with EXE and DLL folders.   With over 125+ projects, I am trying my best to get it down to minimum configuration changes.  I wish I had a better handle of the VS template system.

    Thanks


    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com

    Thursday, April 11, 2019 3:06 PM
  • I would like to add a note and maybe a feature request.

    The reason I needed have different lib folder for each configuration, I don't think the VS2015 IDE has proper logic layout for multiple configurations to automatically set the proper LIB location.    In other words, you have to set it yourself.   Let me clarify this by saying it may depend on where the *.sln solution file is located and that is something I may explore after posting this note.

    Let me explain. The VS IDE defaults will create outputs off the *.SLN file location:

    For 32 bit:

    Output Directory: $(SolutionDir)$(Configuration)\
    Immediate Directory: $(Configuration)\

    For 64 bit:

    Output Directory: $(SolutionDir)$(Platform)\$(Configuration)\
    Immediate Directory: $(Platform)\$(Configuration)\

    So you have the separate locations for the output files.

    But for the Configuration V++ Directories, it has for the Library Directories  the default for the toolset, beginning with:

    Library Directories:  $(VC_LibraryPath_x86);... toolset directories

    In my opinion, what's missing is the $(OuputDir) in the Configuration V++ Directories where you must use DEFAULTS in order to properly support the target toolset.  So for example it should have:

    Library Directories:  $(OutputDir);$(VC_LibraryPath_x86);... toolset directories

    In my past productions, this is where I had the ..\LIB; but that altered the default, therefore, the IDE will not change it when going to the a different toolset.   That was the first gotcha when I began this 64 bit work and that includes the INCLUDE folders as well and also the PATHS for the tools. For example, I noticed that for MIDL, you have to make sure you you explicitly set the 32/64 target for the MIDL compiler.  The CLI box does this properly setting the proper PATH for the 32 or 64 bit tools. So as a basic tip to developers, they should leave the configuration directories unchanged it they want to work with different toolsets.

    But now I need to move the ..\LIB location to the LINKER setup.  No problem if I can use macros.

    So its probably a feature request when you have  *.SLN with related projects of libraries, DLLs and EXEs, and all use the same $(OutputDir) or $(TargetDir),  you should not need to define the Linker additional directories.  

    Make sense?

    Thanks











    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com

    Thursday, April 11, 2019 4:10 PM
  • If you are talking about having an executable project depend on the output of a static library or a dynamic library when they are in the same solution, then Visual Studio already has an answer to that:

    Project references.

    If you reference a project from another, then Visual Studio will automatically link against the output of that project if it is able to.

    In my above example, DllTest.exe references TestDll.dll. Visual Studio will first build TestDll.dll, since DllTest.exe can't build without it. Once that is done, Visual Studio will then build DllTest.exe and automatically add the newly generated TestDll.lib to the linker input of DllTest.exe.

    You can set the reference by simply right clicking on References for the project that you want to add the reference to.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Thursday, April 11, 2019 6:21 PM
  • My copy of VS2015 Update 3 (14.0.25431.01) accepted the macros and saved them to the .vcxproj file -

      <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
        <ClCompile>
          <PrecompiledHeader>Use</PrecompiledHeader>
          <WarningLevel>Level3</WarningLevel>
          <Optimization>Disabled</Optimization>
          <PreprocessorDefinitions>WIN32;_DEBUG;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
          <SDLCheck>true</SDLCheck>
        </ClCompile>
        <Link>
          <SubSystem>Console</SubSystem>
          <GenerateDebugInformation>true</GenerateDebugInformation>
          <AdditionalLibraryDirectories>..Lib\$(PlatformArchitecture)\$(PlatformToolset);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
        </Link>
      </ItemDefinitionGroup>
      <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
        <ClCompile>
          <PrecompiledHeader>Use</PrecompiledHeader>
          <WarningLevel>Level3</WarningLevel>
          <Optimization>Disabled</Optimization>
          <PreprocessorDefinitions>_DEBUG;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
          <SDLCheck>true</SDLCheck>
        </ClCompile>
        <Link>
          <SubSystem>Console</SubSystem>
          <GenerateDebugInformation>true</GenerateDebugInformation>
          <AdditionalLibraryDirectories>..Lib\$(PlatformArchitecture)\$(PlatformToolset);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
        </Link>
      </ItemDefinitionGroup>
      <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
        <ClCompile>
          <WarningLevel>Level3</WarningLevel>
          <PrecompiledHeader>Use</PrecompiledHeader>
          <Optimization>MaxSpeed</Optimization>
          <FunctionLevelLinking>true</FunctionLevelLinking>
          <IntrinsicFunctions>true</IntrinsicFunctions>
          <PreprocessorDefinitions>WIN32;NDEBUG;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
          <SDLCheck>true</SDLCheck>
        </ClCompile>
        <Link>
          <SubSystem>Console</SubSystem>
          <EnableCOMDATFolding>true</EnableCOMDATFolding>
          <OptimizeReferences>true</OptimizeReferences>
          <GenerateDebugInformation>true</GenerateDebugInformation>
          <AdditionalLibraryDirectories>..Lib\$(PlatformArchitecture)\$(PlatformToolset);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
        </Link>
      </ItemDefinitionGroup>
      <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
        <ClCompile>
          <WarningLevel>Level3</WarningLevel>
          <PrecompiledHeader>Use</PrecompiledHeader>
          <Optimization>MaxSpeed</Optimization>
          <FunctionLevelLinking>true</FunctionLevelLinking>
          <IntrinsicFunctions>true</IntrinsicFunctions>
          <PreprocessorDefinitions>NDEBUG;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
          <SDLCheck>true</SDLCheck>
        </ClCompile>
        <Link>
          <SubSystem>Console</SubSystem>
          <EnableCOMDATFolding>true</EnableCOMDATFolding>
          <OptimizeReferences>true</OptimizeReferences>
          <GenerateDebugInformation>true</GenerateDebugInformation>
          <AdditionalLibraryDirectories>..Lib\$(PlatformArchitecture)\$(PlatformToolset);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
        </Link>
      </ItemDefinitionGroup>
    

    Thursday, April 11, 2019 7:29 PM
  • Project Dependencies.... Wonderful!  I'll check that out.



    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com

    Thursday, April 11, 2019 7:49 PM
  • Let me see what VS2015 version I have..... Ok, I have Update 2.  I'll go ahead with finding and installation Update 3.

    Thanks

    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com

    Thursday, April 11, 2019 7:50 PM
  • Also you'll want to make sure that you have the latest VS2015 servicing release for update 3 -- https://docs.microsoft.com/en-us/previous-versions/mt752379(v=vs.140)
    Thursday, April 11, 2019 8:02 PM
  • Applying vs2015-3.exe downloaded from:

    Visual Studio Update 3

    It looks like its going thru the KB30xxx so it might apply the latest kb3165756.   Hopefully it won't take FOREVER so I can get back to work.  :)



    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com


    Thursday, April 11, 2019 9:28 PM
  • I hope it all worked out well.
    Friday, April 12, 2019 9:56 AM