I have combined several projects into one solution. I created empty solution and added these projects and here is a blue print of how it looks like:
Root:
Project1 - directory
Project2 - directory
Debug - directory
Main.sln - file
Now I want to direct the executable and dll from both projects to \debug folder shown up of the solution file. I go into project properites >> Configuration Properities >> General >> 'Output Directory' and change the output directory to $(SolutionDir)$(Configuration)\ which is default for a new project.
The problem is that it has no effect on where the output file is created, it is still created in the old destination. The old path for `Output Directory' was .\Debug\ not that it matters.
Could this be because the SolutionDir & Configuration may not be defined? Where can I see their definition or values? I also want to create a new configuration which would be 'Release with Debug' how can I create that using environment variable? Thanks!
My project is MFC/Visual C++.
Add-on:
Where are these identifiers like SolutionDir defined in the scrip? I look up for in .vcxproj file but there is mention of it. I create a new dummy VS2010 project just to look at it's .vcxproj file but these project settings identified are not defined in any place that I can see!
This is most likely caused by specific settings overriding global settings, namely Linker's "output" setting. This happens often as a result of conversion from earlier Visual Studio.
What you need is to go through every setting, paying attention to those whose values are written in bold, and reset to default (select it from dropdown) every setting with 'debug' or 'release', and others as necessary.
There could also be specific settings on files. I usually resolve this by opening project in notepad and removing any excessive settings. Just be careful. Using multiline replace in Notepad++ or any other capable editor helps.
I think I had a similar problem.
What I ended up doing was editing the vcxproj file directly. Find this section and edit it like this for each of your configurations:
<PropertyGroup>
<OutDir Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">$(SolutionDir)$(Configuration)\</OutDir>
<OutDir Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(SolutionDir)$(Configuration)\</OutDir>
</PropertyGroup>
I had a similar problem with the Intermediate Directory setting in one of my VS2010 projects. No matter what I set it to, it would always use the default value of $(SolutionDir)$Configuration. Oddly, other projects in the same solution with the same settings worked just fine.
After playing around, I stumbled upon a solution.
Click on the setting in the propery page dialog.
Click on the down arrow button in the right-hand side of the edit box.
Select "inherit from parent or project defaults".
Click "Apply".
Click on the setting and change it to your desired value.
I don't know why this works, but it does. It seems like the macros were not being properly evaluated for whatever reason. Then, after you apply the inherited values, it seems to reset itself and start evaluating the macros properly.
Related
I have the following version of Visual Studio:
Microsoft Visual Studio Community 2017 Version 15.1 (26403.7) Release
VisualStudio.15.Release/15.1.0+26403.7
I created a new project and added a .editorconfig file at my solution base folder.
Its content is the following:
root = true
[*.cs]
indent_style = space:warning
indent_size = 12:warning
# C# and Visual Basic code style settings:
[{*.cs,*.vb}]
dotnet_style_qualification_for_field = false:warning
The file location should be right:
.editorconfig <-- Here it is
ApplicationInsights.config
App_Data
App_Start
bin
Content
Controllers
favicon.ico
fonts
Global.asax
Global.asax.cs
Models
obj
packages.config
Properties
Scripts
Startup.cs
Views
Web.config
Web.config.backup.1
Web.Debug.config
Web.Release.config
WebApplication8.csproj
WebApplication8.csproj.user
But whenever I edit a .cs file, nothing special happen (despite indentation not following the rule), I expect a warning (after a build, for instance) to show up, but no.
Is there something wrong with my configuration, or is there something which could hinder the configuration from being applied?
I had this same problem. The solution was adding the .editorconfig file to the solution in my case. You can choose to either add it to the solution or the project, depending on whether you want it applied everywhere or just the individual project.
Solution Explorer → right-click your solution or project → Add → Existing Item... (if you have the .editorconfig file in position at the root of the solution or project) or New Item... (then search for editorconfig in the Add New Item wizard and choose the appropriate type for your work).
I solved a similar issue by placing the .editorconfig file at the root folder of the project, i.e., the same folder as your .sln file.
Try to put the .editorconfig file into the same folder as your source file. If it helps, try to move it up (into one of the parent directories) until you get it high enough to affect all the files you need.
If you have any EditorConfig extensions installed, try to uninstall them. There were some related bugs reported.
I had a similar problem and this is how I solved it:
My solution folder had a parent folder named between square brackets [], like [ParentFolderName], so I removed the square brackets and everything worked as expected.
For a reason or another, the editorconfig file does not do anything when the solution folder has a parent folder named between square brackets. The IDE (in my case Visual Studio 2017) uses its settings.
I'm working in MFC (C++11)in VS2015 and I have a set of standalone GUIs that i'd like to use across multiple projects. I know this is possible by creating a .rc file that can be included in the main .rc file of each project based on this:
Using Multiple Resource Files
While conceptually I understand what it is describing, i can't find any example of creating the standalone .rc file and second resource file. I created a test resource header file that lives globally in my solution and tried to include it using Resource Includes, but it can't find it, even with the path. Can anyone point me to links or examples on how to set this up?
I have either .rci files, that are never used with the resource editor. They are used with #include freely.
Or I have special .rc files that contain standard symbols and messages, that are used over a larger set of projects.
I just simply add the second rc file to the project. This resource file is simply #include'ed into the main .rc file of the project.
To prevent errors in the project. This second .rc file is excluded from the build. In the solution explorer right click on the item. And set Exclude from Build to YES.
Take care about collisions of IDs.
Here is how I do it. If you drop the resource you would like to include on the resource folder in the solution explorer, it will show up as a separate and editable resource in your project
You will have to include the headers in your project that go along with them, of course. So watch out for collisions of your IDs. You may have to go to the new resource and use IDs that have been set aside by adjusting _APS_NEXT_XXX_VALUE. I've never used the 'Resources Includes..'. as described in TN035. I just checked and relative paths to bitmaps seems to work fine. Hope that helps.
I know two approaches of doing it. I will demonstrate it assuming you want it for the need of managing the fact your application supports several languages.
The first one is already described by user #xMRi, and depending on your configuration/platform you will include only the .rc in question. For example you have configurations:
en_GB
fr_FR
pt_PT
de_DE
and files
Project_en_GB.rc
Project_fr_FR.rc
Project_pt_PT.rc
Project_de_DE.rc
For getting this right, you will need to do Exclude from build on them all, except on the Configuration you have selected at the moment on the VS Toolbar combo. If you have fr_FR selected, do Exclude from build of all other .rc except Project_fr_FR.rc files and apply the same logic on every configuration.
The other is to have a VS project (vcproj) for each language, where each project contains the .rc file brlonging to it.
The projects
Project_en_GB
Project_fr_FR
Project_pt_PT
Project_de_DE
contain respectively
Project_en_GB.rc
Project_fr_FR.rc
Project_pt_PT.rc
Project_de_DE.rc
Here at work we use both (I never heard of .rci files before; we use the first with normal .rc files), depending on the project.
I'm trying to compile a C++ type .DLL for a SierraChart custom study.
(Which is a financial trading application.) Here is the warning I get that I need to fix so it all points to the linker output value:
warning MSB8012:
TargetPath(C:\SierraChart\VCProject\Release\SCStudies.dll) does not match the Linker's
OutputFile property value (c:\sierrachart\data\SCStudies.dll).
This may cause your project to build incorrectly. To correct this, please
make sure that $(OutDir), $(TargetName) and $(TargetExt)
property values match the value specified in %(Link.OutputFile).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets
Any idea what's wrong?
I believe this warning appears specifically when upgrading a C++ project to VS2010. Visual Studio 2010 C++ Project Upgrade Guide describes some of the caveats encountered during an upgrade. If you're uncomfortable changing project settings, then retaining the older version of Visual Studio, may work for you.
To change the %(Link.OutputFile), open the project properties. Navigate to Configuration Properties -> Linker -> General. You can set the Output File to $(OutDir)\SCStudies.dll, which should take care of your issue. You may need to repeat the change for each Configuration/Flavor you will be building (Debug/x86, Release/x86, Debug/Itanium, etc...).
Based on this answer.
I changed the following property:
Linker -> General -> Output File to
"$(OutDir)$(TargetName)$(TargetExt)"
This prevented the warning to appear and the output was generated successfully.
The original configuration was set like:
Properties -> Linker -> General : $(OutDir)\"<'name fileA>".exe
The program tries to run "<'name_project>".exe and as result error Linked.
You need to set the configuration as:
Properties -> Linker -> General : $(OutDir)\"<'project name>".exe
A different fix which others haven't mentioned is that by default the TargetExt is .exe and for my debug builds I changed it to be _d.exe, where instead you should be doing that in the TargetName path.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
If you want to change the defaults do things in these order:
You first configure the OutDir in General->Output Directory. E.g.
$(SolutionDir)$(Platform)\$(Configuration)\MyProgram\
Make sure Output File is consistent. E.g. this would work
$(OutDir)\$(TargetName)$(TargetExt)
The comment from Gerardo Hernandez helped me.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
In my case I was importing a large project from Visual Studio 6 and
C:\Project\myproject\OneOfMyDlls\.\Debug\OneOfMyDlls.dll
was not equal to
C:\Project\myproject\Debug\OneOfMyDlls.dll
but
C:\Project\myproject\OneOfMyDlls\..\Debug\OneOfMyDlls.dll
would have been, after path reduction.
The problem was that the Visual Studio 2017 import had changed the output directory from
..\Debug to .\Debug assuming that the unconventional parent directory use was a mistake. In a large project with 13 DLLs of our own, (never mind second and third party DLLs too), it makes sense to collect all the DLLs in one place and ..\Debug was correct.
So while others might have had to change Linker->Output File, in my case it was General->Output Directory which needed to change as it had been corrupted by the import from Visual Studio 6.
Something like ..\Debug had become something like .\Debug after import. (The real project specific names have been removed .)
Looks like it's not significant for the program:
Odd Visual Studio error when following the custom study video
If, like me, you return to Visual Studio after 20 years, you may not know where the project properties are. In VS 2012: top of the screen "FILE EDIT VIEW PROJECT BUILD..." : choose PROJECT. Properties is the last item in the menu. Indeed for me there was a mismatch in the target name, too.
I have a two projects, AI and Core, which used to hold a circular dependency. I have a CoreUtilities file that I have broken up to remove this dependency, and added the functions I have removed to a new file called AIUtilities(.cpp/.h).
I then went to the piece in my AI project that uses these functions and added #include "AI/AIUtilities.h" and changed the function call from CoreUtilities::Functionname to AIUtilities::Functionname. Upon compile, I recieved the error given in the title.
Why! How can I fix it?
Did you update your project settings with the path to the direcory containing AI/AIUtilities?
Update:
From the solution explorer window, right click on your project and choose "properties" then a new windows "your_project_name property page" will pop up.
In this window on the left pane you'll see a tree. Click on 'Configuration properties' which expands to multiple choices. Continue clicking on 'C/C++' then on General. On the right pane appears multiple properties that affect your project.
Choose the "Additional include directories" property and add the path to your new directory. For instance if your path is : "C:\AI\AIUtilities.h" add the following: "C:\" in the property.
Click on "Aplpy button". Done.
As mentioned in other post, you must consider that moving your project around will break your project settings. Don't forget to update them. Or use either environnement variable to set the root of your project or use the "../../" trick. But personnaly I prefer the former.
You need to ensure that the parent directory of AI is on your header include path. Assuming that your code is laid out like this:
blah/source/
AI/
AIUtilities.h
AIUtilities.cpp
Core/
CoreUtilities.h
CoreUtilities.cpp
So either you need to have the header search path to '/blah/Source' or '..' depending on how your directories are structured.
Note that if you have sub-directories inside each project then this can cause problems with resolving the header search path. In that case set the header search path to $(ProjectDir)\.. .
I have been through every option to try to find a way to get the IDE to let me create a new win32pject without precompiled headers. I have read every thread on this forum with the words "precpmpiled headers" in it and the closest I got was:
Precompiled Headers
Using 2008 pro (not express, althought the behaviour seems to be similar) I go to:
File -> New -> Project
This opens the New Project dialog in which I select Visual C++ Win32 Project, enter a name and hit OK.
THen I get the "Win32 Application Wizard". With the Application Type set to "Windows Application", the application settings pane will not allow me to uncheck the pre-compiled headers. THe check box is greyed out. IF I choose "Console Application" I can uncheck it, but I am creating a GUI app.
WHen I click Finish I get 6 yards of code in xxx.cpp, four header files and the obligatory stdafx.cpp.
Perhaps I could remove and delete all this stuff and the go into the properties and turn off PCH, but thats a hasssel for the many small project examples I want to write.
I just want an empty project that will compile to a win32 app, so how do i change the PCH default to NONE?
You could make your own template to do this, or you could edit the default one. The relevant wizard can be found here:
C:\Program Files\Microsoft Visual Studio 9.0\VC\VCWizards\AppWiz\Generic\Application
Obviously if you're gonna edit the default template, backup the folder first.
I'll show you how to get started on editing it.
First of all you need to tell the wizard script that you don't want precompiled headers. Edit this file in your favourite text editor:
\scripts\1033\default.js
Find this line:
var Pch = wizard.FindSymbol("PRE_COMPILED_HEADER");
and comment out some of the lines below it like this:
// if ((strAppType == "LIB" || ((strAppType == "CONSOLE") &&
// !wizard.FindSymbol("SUPPORT_MFC") && !wizard.FindSymbol("SUPPORT_ATL"))) && !Pch)
{
AddFilesToProjectWithInfFile(selProj, strProjectName);
SetNoPchSettings(selProj);
}
// else
// {
// AddFilesToProjectWithInfFile(selProj, strProjectName);
// SetCommonPchSettings(selProj);
// }
Now open this file:
\templates\1033\Templates.inf
and find the first occurrence of [!else] and delete these 3 lines below it:
stdafx.h
targetver.h
stdafx.cpp
This will give you a project without stdafx.cpp/.h or targetver.h, and the CPP file will not try to use a PCH. However it won't build because we haven't added any #includes to the appropriate header files. I'll leave that for you to figure out :)
(you can edit the files that get generated automatically by modifying the files in \templates\1033)
either choose an empty project, or create your own wizard in which you use a template. Since you say you don't want to change properties the whole time, I'd also strongly suggest using property sheets (vsprops). This way, you create an empty project, add the property sheets you want, and you'r ready to go. No more fiddling with properties, and each project uses the same set.
Mark the "Empty Project" check box in the "additional options", in the Application Settings dialog.
The "Empty Project" option will create a project without precompiled headers. At least, this is what I get on Visual Studio 2008 SP1.
It's true that the "Use precompiled headers" remain checked, but the project will have the property UsePrecompiledHeader="0" and the wizard won't create the files.
I'm jumping way late on this bandwagon, as I'm having the same issues for VS2010.
I'm not sure if this solution would apply for VS2008.
Since there are no settings or options under tools which would enable me to default to an empty project, I searched around and found the following:
in the folder
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\VCWizards\AppWiz\Generic\Application\html\1033
there is a file named default.htm
in the </HEAD> section, there are two lines:
<SYMBOL NAME="EMPTY_PROJECT" TYPE=checkbox VALUE=false></SYMBOL>
<SYMBOL NAME="PRE_COMPILED_HEADER" TYPE=checkbox VALUE=true></SYMBOL>
which I replaced with
<SYMBOL NAME="EMPTY_PROJECT" TYPE=checkbox VALUE=true></SYMBOL>
<SYMBOL NAME="PRE_COMPILED_HEADER" TYPE=checkbox VALUE=false></SYMBOL>
(in other words, I just switched true and false on those lines)
and now I have an empty project by default when I create a console app.
I don't know the repercussions as to what it will affect when I do something other than console apps, but since I saved the original file, I can just revert to the old M$ settings.
You can just select 'empty project' under 'additional options'. Then you get a project with no precompiled headers, and no autogenerated files.
I don't know what it is with Microsoft's obsession with forcing precompiled headers even in the smallest test project. Presumably it's based in the same philosphy that gave us the macro hell that is windows.h, or the way even an empty project overrides two dozen project settings, making property sheets almost useless.
I suspect there's simply a strong mafia inside Microsoft's developer division, who's doing everything they can to prevent Visual Studio from becoming a useful tool for C++ developers. So far, they're doing a very good job of it.