Hi by mistake I added cv210d.lib, cxcore210d.lib and highgui210d.lib as inherited values under the project configuration->Linker->input->Additional Dependencies settings.
But I cannot seem to remove them from the "inherited" additional dependencies. So each time I start a new project I get an error because these liberties cannot be found.
There is an option to ignore the inherited dependencies but I cannot do this as it contains values I do need.
So I am looking for a way to remove these unwanted values from the "inherited" additional dependencies.
You can find the file "Microsoft.Cpp.Win32.user" on your system and manually edit it as you want. Normally the file will be located at "C:\Users\%USERPROFILE%\AppData\Local\Microsoft\MSBuild\v4.0" location. It is an xml file.
As was suggested I modified the property sheet in the property manager.
The reason I found it confusing though was that in the Property Manager view, there are three different ways to change the properties. Through clicking on the debug, release property sheets or the project properties . But when I opened each one I thought I was opening the same thing, as they look similar.
But the case is that, the properties from the debug and release property sheets are inherited to the project properties. And you cannot modify the inherited properties from the project properties.
Did you accidentally add it to "Linker > Input" under "Property Manager > AnyProject > AnyConfiguration > Microsoft.Cpp.Win32.user"?
Despite its strange position, this is the setting for all projects of the current user.
As soon as you put a wrong .lib file into Additional Dependencies it went to the inherited directory. You need to untick "Inherit from parent or project defaults". Then, to save inherited .lib files (such kernel.lib and etc.) you need to copy and paste all of them into the Additional Dependencies directory. So your computer cannot take the wrong .lib file and will use only Additional Dependencies which you wrote
You can open with notepad the .vcxproj file of your project and find the lib you want to remove. Then, Delete that library from the xml field.
Related
Context: setting up the Assembly Name/Default namespace in the Project Properties (right click on project, Properties, Application tab; or edit the .csproj).
I would like to add a parameter there to explicitly have them following the Project Name, plus some custom suffix. So if I rename my project, the Assembly name/namespace follow that rename.
Example: project named foo → foo_suffix.dll. If I rename the project to foo1 → foo1_suffix.dll.
Same behaviour for the namespace.
Reading Common macros for MSBuild commands and properties,
I tried inputting $(ProjectName) both in VS and in the .csproj file, but I get a .dll named exactly like that.
How can I get this done?
How can I get this done?
1. Try using $(MSBuildProjectName) property from this document.
You're developing a C# project(csproj) while your document above is about macros in C++ projects(vcxproj). So I think $(MSBuildProjectName) property can be more suitable for you after my several tests.
(I tried $(ProjectName), but it only worked well when I set something like <AssemblyName>$(ProjectName)</AssemblyName>, if I add a suffix like $(ProjectName)_suffix, the output sometimes is _suffix.dll. But it always work well if I use $(MSBuildProjectName)!)
I get the desired behaviour, but that is inconsistent with what I can
see in project, Properties, Application tab.
2. Try reloading the project file(Right-click project, unload.., reload...) to Update the UI.
From your comment, it seems like the $(ProjectName)_suffix works well in your machine? If so, you can still use $(ProjectName) property.
What you experienced is expected behavior for Msbuild and VS. VS will read value from csproj during project loading process. Then it display the related value by UI.
So after we rename the project name and then build the project, we can get a ProjectName_suffix.dll in output folder. But the UI is still not changed(inconsistent), cause now we need to Update the UI.
You can right-click project node, unload the project=>reload the project to get UI updated. And now the output xx.dll can be consistent with what you see in project, Properties, Application tab. It needs us to reload the project each time after you rename the project, then the UI would be consistent with your xx.dll. And actually it won't affect your build though the UI is not updated, the output can be your desired behaviour.
3. All above is more related to the relationship between Assembly Name and Project Name. One point you should know is msbuild(csproj) won't modify the source files(xx.cs) after the project is created.
So assuming you have a Class1.cs file whose namespace is Library. If you rename the project to NewLibrary, reload the project and you can see the Namespace is NewLibrary now in project, Properties, Application tab. But the namespace for Class1.cs file is still old Library. This is expected behavior in VS, and the new NameSpace NewLibrary would work if you create a new xx.cs file.
Hope all above helps :)
I added a filter and some .c files to my .vcxproj through the GUI but they won't build correctly because I'm in the process of adding all the correct environment variables.
Is it possible to temporarily exclude from the build a filter and its children?
As the name says, 'filter' is just view filter and has no effect on build system, thus, there is no easy way. You can only modify project and source files properties ('Excluded from build' of cpp in your case).
But... there is a workaround, which makes you edit all cpp files only once and works for all build configurations.
Create props file (View->Other Windows -> Property manager, right mouse button on your project and 'Add new...') and in User Macros add TempExclude with value 'Yes'
Now select all problematic files and in Excluded from Build type $(TempExclude) (Don't forget to select All Configurations and All Platforms)
Now you can edit just value of TempExclude in property file to get you files in/out build. If you dont define TempExclude it will include files into build.
I have created several user-defined build settings in Xcode 4.3.1. I no longer need these settings and want to delete them, but there doesn't seem to be a way to delete them!
I am aware that these are stored in the project settings (project.pbxproj) file located within the xcodeproj file. But I don't want to edit these in a text editor as there are all sorts of repetitions and guids which I don't understand.
Any suggestions on how I can do this within Xcode? (or have they forgotten to add a "delete" button)
Just figured this out myself: you need to make sure you're at the right scope to be able to delete the setting. If you defined the setting at the project scope, no amount of key-bashing will remove it if you're looking at the target-scope. Remember, targets inherit settings from project scope. That last bit is what I tripped over :)
Try selecting a user-defined setting that you created then hit "Delete" button on your keyboard. That works for me when I encountered the same problem.
On Xcode 6:
Select the row and hit Fn + Delete.
Follow the steps below:
Select Project
Tap on the Info tab
Select Configurations
Select Configuration to remove
Press the Delete button on the keyboard
Removing User-Defined build settings depends on where those settings have been created.
Lets assume that you've created one already and named it as PROJECT_SETTING. In order to check your PROJECT related User-Defined settings, you have to select your project first on the project and targets list, then you should see something like this:
Here you can see only PROJECT related settings, and here you have the
only ability edit/delete PROJECT_SETTING.
Besides that if you set up a TARGET, so can add new User-Defined settings there, that only affects that TARGET scope.
You can edit/delete TARGET_SETTING_1 and TARGET_SETTING_2 here, but
PROJECT_SETTING is read-only, as it is inherited from your
PROJECT settings.
Here you will notice that your TARGET contains your PROJECT User-Defined settings and also your TARGET related User-Defined settings marked as bold letters. This helps you to know which setting can be edited on this level.
You won't be able to delete your settings here if that was created under PROJECT scope, and also editing a PROJECT related User-Defined settings will result a newly created settings that affects only the selected TARGET.
Also if you prefer more visibility on Build Settings, you can select Levels view instead of Combined view, so you should see it more separated:
Select one of them and press keyboard's delete button.
There's a caveat to these answers: If you're using a Build Configuration File (.xcconfig) it doesn't seem possible to delete the user-defined settings generated from these files directly on either the project or target level in the "Build Settings" GUI. You'll have to delete the flag and its value from the configuration file and rebuild the project. If you're using multiple build configuration files that use the same flag, you'll have to delete them from each file.
Although settings that come from these configuration files are displayed in the User Defined build settings section (just like any other user-defined flag that one would create from the GUI), they are not written to the .xcodeproj file like the settings that one adds from the GUI are (which probably prevents them from being able to be deleted from the GUI). They are also not displayed in bold text like these GUI-added settings are.
I'm trying to change a namespace in Visual Studio.
My folder structure looks something like this:
GameAlpha/
GameAlpha.sln
GameAlphaRelease/
GameAlphaTest/
GameAlphaLevelEditor/
These include namespaces like GameAlphaRelease. I want to change all this to GameBetaRelease.
Before this process, it built fine.
First, I changed the solution and project files from Alpha to Beta. Then, I did a "find-replace-all" on the namespace. Finally, I went through the properties of each project and changed the "Assembly Name" and "Default Namespace" to the appropriate Beta title.
However, now the solution does not build. The error is:
GameAlpha.accessor: The reference to 'GameAlpha.exe' was not found in
the list of this projects references.
(Project: GameBetaTest)
What am I doing wrong? If I remove project GameBetaTest, the solution builds just fine.
Also, what is the preferable way to change the names of the folders in the file system?
The following steps normally work for me:
Use the standard project rename (this renames the project, but not the Project Directory). If you want to change the directory as well, close down the solution, rename the directory, open the solution, remove the old project (which is now unavailable) and add the project from the new location.
For each project for which it applies, remove and re-add references to other projects in the solution if there are any inter-project dependencies.
Adjust the project properties for each changed project.
Verify/adjust build scripts.
Verify/adjust the build order.
Clean and rebuild all.
If you do a package/class rename, make sure you do it separately (before, while everything is "still working") so that VS will update the internals as required. YMMV and there are some issues with files "linked" between projects.
Rename the physical project directory
Note: The physical path property is recorded in the .sln file so you cannot just rename the folder in Explorer.
a. Close the solution and the IDE
b. In Explorer: Change the directory name to the new name.
c. In Explorer: Open the .sln file with a text editor.
c. Change the directory name to the new name and save.
d. Restart the IDE and open the solution from the File, Recent Files menu if it doesn't start automatically.
e. Click on the Project folder of the Solution Explorer and check the path property in the properties at the bottom. It will now be referencing to the new project folder.
Here I found it
I'm using Visual Studio 2008 and would like to create a sort of container project that holds a number of DLL's that must be installed with a solution. I want them to be in a separate project so that they can be easily attached to a solution as a group.
I created an empty project call TEST, added my DLL's to it with a Build Action of "Content", and set them to "Copy Always". That all works exactly as I want. The problem is that if I set the TEST project Output Type to "Console Application" or "Windows Application" that it won't build because there's no entry point. If I set the Output Type to "Class Library", it builds but I end up with an extra TEST.DLL file that I don't really want.
Is there anyway to sort of set the Output Type to "none"? I want the build actions to take place (so my DLL's get copied) but I don't want the dummy class assembly created. Any ideas?
Thanks!
Assumptions for the following step-by-step guide:
Let's assume that you have a solution with two projects:
Main: your main (start-up) project.
BundledDLLs: a library project which contains the .dlls that should end up in the main project's output directory.
Step-by-step guide:
The easiest way to achieve your goal inside Visual Studio is probably the following:
Add all .dlls to BundledDLLs and set their Copy to output directory to Copy if newer.
This is done in the Project Explorer and the Properties windows.
Configure BundledDLLs's output directory to be identical to Main's output directory.
This can be done in the Build tab of BundledDLL's Project Properties page. Enter something like the following in the Output Path textbox:
..\Main\bin\Debug
Set up BundledDLLs as a dependency of Main.
Do not add BundledDLLs as a project reference to Main, as you usually might; instead, use the Project Dependencies dialog to . This will tell the build tool that whenever Main is built, BundledDLLs needs to be built first.
Do this by right-clicking on the Main project node to open the context menu; select Project dependencies... from there. In the now opened dialog, first select Main from the drop-down list; then check BundledDLLs in the project list below. BundledDLLs is now registered as a dependency of Main.
P.S.: One disadvantage of not having an explicit assembly reference in Main is that some tooling might not recognise the dependency. For example, ClickOnce deployment might not work properly.
Add a post-build event to BundledDLLs that deletes the superfluous BundledDLLs.dll.
As you said, you don't want, and don't need, the dummy output generated when BundledDLLs is built. So add a post-build event that simply deletes this .dll once it's been created.
Open the Build events tab in BundledDLLs's Project Properties page, and enter something like the following in the post-build textbox:
DEL "$(TargetDir)\$(TargetName).*"
(In case you wondered: The reason why you didn't add this project as a project reference to Main earlier is because if you had done so, Main would be looking for BundledDLLs.dll, which it wouldn't be able to find since you don't actually want such a file to be generated.)
P.S.: One disadvantage of adding such a post-build step is that it might interfere with incremental builds. If your project keeps getting recompiled from scratch after this, you might be better off removing the post-build step and living with the extra BundledDLLs.dll in your solution's output directory.
Another option is to use a makefile project, which doesn't require you to build/link anything.
In your project properties (right click property in solution explorer and click "Properties"), under "Configuration Properties" and then under "General", choose "Makefile" from the "Configuration Type" drop-down menu. The build output will include the warning "The property 'NMakeBuildCommandLine' doesn't exist...Skipping" but the build will succeed without building any dll/exe/etc.
While other answers here may better address your specific need, specifying a makefile more directly answers the question title "Possible to create Visual Studio project with Output Type of none?" I hope this is useful for people who google something to that effect and land here.
Credit goes to Xeek in the #winapi freenode irc channel for sharing this tip.
Instead of putting them in a project, you can put the files in a Solution Folder. One of your projects can have a build action that does the copying, but since they won't be in a project, they won't try to "build".