I have discovered Property Manager in Visual Studio 2010. However there are two project properties that I haven't found how to set a default value for. Under Project Defaults in the project property pages dialog window, there is Configuration Type property whose default value is Application (.exe). I would like the default to be Dynamic Library (.dll). The other property is Character Set whose default value is Use Multi-Byte Character Set but I would like it to be Use Unicode Character Set.
Please note that I have also discovered the file Microsoft.Cpp.props but it contains a warning not to edit the file's contents - so I would prefer not to.
Is it possible to set the defaults I desire and if so, how do I do it?
Related
I'm developing in BizTalk 2013R2 using Visual Studio 2013, trying to create a property schema based on a large, lengthy source schema using Quick Promotion, however I'm having difficulty getting the created property schema generated properly.
Essentially we are trying to adhere to cleaner development standards that mean BizTalk solution artefacts are nested within their own relevant folders, but some of the automated functionality of the VS SDK for BizTalk is making this seemingly impossible.
Is it possible to create a Property Schema in a specific directory within your solution root?
I don't seem to be able to enter a full filepath into the 'Default Property Schema' option on the source schema properties, as it errors with an 'illegal characters' warning for spaces and backslashes in the filepaths string.
I've tried using HTML encoding, escape characters and encapsulating it as a string, but they just return the same error each time.
I've also tried generating the schema in the root source, and then moving it manually into my target folder, changing the namespace accordingly to reflect its new location, but this loses it's connection within the source property schema and causes the link to break.
Yes, it is possible
After you have done your quick promotion, go into the Promote Properties and remove the Promoted Properties (1) and then the schema (2)
After that move and change the namespace of the Promoted Properties schema.
And then browse for the property schema (1) in the Promote Properties dialog and then select the item to promoted (2), click Add (3) and if you have more than one promoted property assign it to the correct one (4).
If I run my app on an UWP device I get the following warning in the Output window:
MakePRI : warning 0xdef00522: Resources found for language(s) 'en,de' but no resources found for default language(s): 'de-DE,en-US'. Change the default language or qualify resources with the default language. http://go.microsoft.com/fwlink/?LinkId=231899
Don't know if this is related, but I also get
1>C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2459,5): warning : APPX4001: Build property AppxBundlePlatforms is not explicitly set and is calculated based on currently building architecture. Use 'Create App Package' wizard or edit project file to set it.
This page states, that I have language specific resources, which I haven't qualified with the language tag. How can I find out, which resources these are?
I have images in the Assets folder, but they are language independent ones. Furthermore, I've set the default language in the Package.appxmanifest to de-DE. If I search for the language abbrevation from the warning, I can only find a priconfig.xml and AppxManifest.xml, both in the Debug output folder.
What should I do to remove this warning?
Edit:
The warning seems to disappear if I add a AppResources.en-US.resx file (currently I have en-US set as default language in Package.appxmanifest). Additionally, I have a file for AppResources.de.resx and AppResources.resx (should be en). But why does the sample project doesn't need such a file, despite there should be the same settings? What I'm missing?
The warning seems to disappear if I add a AppResources.en-US.resx file (currently I have en-US set as default language in Package.appxmanifest). Additionally, I have a file for AppResources.de.resx and AppResources.resx (should be en). But why does the sample project doesn't need such a file, despite there should be the same settings? What I'm missing?
As you said, the AppResources.resx is en. And you could expand the Properties node in the Portable Class Library (PCL) project and double-click on the AssemblyInfo.cs file. Add the following line to the file to set the neutral resources assembly language to English:
[assembly: NeutralResourcesLanguage("en")]
This informs the resource manager of the app's default culture, therefore ensuring that the strings defined in the language neutral RESX file (AppResources.resx) will be displayed when the app is running in one the English locales.
You have set en-US as default language in Package.appxmanifest, However, there is no such file corresponding to it. So it will throw warning.
The default language of the sample project is en-US, and there is no such file corresponding to it. It also throw the same warning in my side. if you modify the default language to en, the warning disappear. Because it has set AppResources.resx as en in AssemblyInfo.cs file.
Foe more you could refer to AssemblyInfo, Supported languages.
Just to extend answer from Nico Zhu - MSFT
if you are using .Net Standard there is no assemblyInfo.cs file because everything is stored in the csproj file. So just go to properties of the shared project and change the Project neutral language to whatever your resx default file is.
or you can right click on the project and edit the project and the line below.
For me problem was,after converting from PCL to Net Standard, suddently UWP application wasnt picking the default resource file which was en-US. I recognized because i was having this setting in assmeblyInfo.cs and since It was removed, it didnt work. But somehow it works fine for Android project.
<PropertyGroup>
<NeutralLanguage>en-US</NeutralLanguage>
</PropertyGroup>
I looked at some projects generated by the Qt plugin for VS and noticed that they use the environment variable QTDIR to refer for example to the Qt header files. However I failed to figure out where this variable is set. I guess it must be somewhere in the project settings, however I could not find it. Also please note that I am referring to the environment variables required during the build, not the ones for debugging.
On Windows there are two ways to set an environment variable like QTDIR: either permanently in System Properties->Advanced->Environment Variables or temporarily for a single cmd session by opening cmd.exe and executing set QTDIR=/path/to/qt; now when starting VS from that commandline (execute devenv.exe) it will use the QTDIR value just set. The second case you use mainly when you have multiple QT installations.
Apart from that, you can also use User Macros in VS Property sheets. From the build tools' point of view they are sort of equivalent to environment variables. Add a new property sheet to your project, double click on the new sheet, go to the User Macros page and click on Add Macro. Nice thing is you can share this property sheet amongst all your Qt projects.
When you install Qt through the setup wizard (i.e. not manually), the installation process sets the system environment variable QTDIR. This is not a project-specific thing, it is set for your whole system. You can check that at the location stijn described.
Hint: You can press Win+Pause to open the system properties dialog (where Win is the key between Ctrl and Alt)
I am creating a desktop app that needs to install an SDF file to the SpecialFolder.CommonDocuments folder (C:\Users\Public\documents in Win 7). In a Visual Studio desktop Deployment Project, how do I specify this folder in the File System Editor?
I tried creating a custom folder in the File System Editor and pointing it to the CommonDocuments folder in the Properties pane, like this:
Unfortunately, that specification won't build. I don't want to hard-code a folder path, since it varies between Windows versions. So, how do I specify the CommonDocuments folder in the FileSystem Editor? Thanks for your help.
I figured this one out and documented it for internal purposes. So, I'll just reprint that writeup here:
Visual Studio deployment projects don't support the CommonDocuments folder directly, but we can add that support by using the Launch Conditions Editor, which has a "Search Target Machine" task. We will use the task to search the Windows registry for the path to the Public Documents folder and assign the result to an installer property (actually a variable) called COMDOCFOLDER. We will then use that variable to set the path to a custom folder in the File System Editor.
Here are the steps to perform the task. First, open the Launch Conditions Editor in a Visual Studio deployment project:
Right-click 'Search Target Machine' and select 'Add Registry Search' from the Context menu. A new item will appear (see 1 above). Name it Get Common Documents Folder. In the properties pane (See 2 above), set the 'Property' property (the name of our variable) to COMDOCFOLDER, set the 'Root' property (the Registry root key to search) to vsdrrHKLM, and set the 'RegKey' property (The Registry key to find) to SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders. Notice that we omitted the root key from the 'RegKey' Property. Finally, set the 'Value' property (The name of the value we are searching for within the registry key) to Common Documents. The COMDOCFOLDER variable will now hold the path to the Public Documents folder.
Next, go to the File System Editor in the Visual Studio deployment project:
Right-click 'File System on Target Machine' and select 'Add Special Folder > Custom Folder' from the context menu. A new item will appear (see 1 above). Rename the item Common Documents. In the properties pane (See 2 above), set the 'Property' property to COMDOCFOLDER. I set the 'DefaultLocation' property to the hard-coded value of the CommonDocuments folder for Windows Vista and later; this value would only be used if the COMDOCFOLDER property returned a null value, which shouldn't happen. The installer now has a Common Documents folder that points to the Public Documents folder, as specified in the Windows Registry.
There is more information in this Microsoft Support How-To.
The answer of David Veeneman is great! Helped a lot.
A little correction:
Right-click 'File System on Target Machine' and select 'Add Special Folder > Custom Folder' from the context menu. A new item will appear (see 1 above). Rename the item Common Documents. In the properties pane (See 2 above), set the 'Property' property to
[COMDOCFOLDER]
Those square brackets are necessary, otherwise you'll receive exception while executing the installer.
I'm trying to build gtest on Visual Studio 2010. After converting the solution file, I tried to build, and I got the following warning messages.
Warning 1 warning MSB8012:
TargetPath(C:\Users\sucho\Desktop\gtest-1.5.0\msvc\gtest/Debug\gtest.lib) does not match
the Library's OutputFile property value (C:\Users\sucho\Desktop\gtest-1.5.0\msvc\gtest\
Debug\gtestd.lib).
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 %(Lib.OutputFile).
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets
The message says I need to setup variables $(OutDir), $(TargetName) and $(TargetExt), together with property values specified in %(Lib.OutputFile).
How can I do that with Visual Studio (especially VS 2010)?
I see it. Right-click the gtest project, Properties, Configuration properties, General. Ensure that the Debug configuration is selected (upper left combo). Change the Target Name property to
$(ProjectName)d
Note the added "d" to change the name from gtest to gtestd. The warning is otherwise benign.
I think no one has the right answer, i solved this way: in project properties pages, check if linker->General->Output file match configuration properties->General->target name & configuration properties->General->target extension.
You don't need to add any 'd', of course, is more simple set to Inherit from parent or project defaults, for all 3 variables.
Example:
Linker → General → Output File = "myproject.exe"
then:
Configuration Properties → General → Target Name = "myproject"
configuration properties → General → Target Extension = ".exe"
The warning is spurious -- assuming you're using Google Test, it works just fine
You can make it go away however. Right click on the offending project and select properties. Select "Librarian" in the tree view on the left hand side, and change the "Output File" item on the right by clicking on the box next to output file, and selecting "Inherit from parent or project defaults".
The background to this is that Microsoft changed the meaning of the $(TargetName) macro. It used to mean "whatever filename you put in Linker | Output File, minus the extension". They changed it to "by default, the name of your project". (This is something you should never do, in my view; they should have added a new macro).
Whereas VS2008 and earlier were able to parse the file name out of the Linker setting, apparently they were not able to parse it out in the migration to newer versions, leaving our configurations broken.
The warning itself is probably not important, but if you use $(TargetName), say by passing it to a batch file, this change will break your batch process.
For us, the solution has been to copy the file name (minus extension) from Linker | Output File to General | Target Name, and then set Linker | Output File to "inherit from parent/default". This is because we use suffixes like "d" (for debug), "u" for Unicode, _64 for 64-bit and so forth.
On the other hand, if your output file always matches the name of the project, then all you need to do is set Linker | Output File to "inherit default" and you're done, in principle - providing that the output directory you want for your compiled file matches General | Output Directory.
This change is absolutely infuriating because it involves moving literally hundreds of settings around, all due to sheer laziness on Microsoft's part, as far as I can see.
I was just trying to compile an application in Visual Studio 2019 that I had last compiled in Visual Studio 2005. I encountered the same warning.
I thought I would show what I did visually with screen shots.
Solution Name v Target Name
As you can see, my variables were both set to Import Text:
I could have just set the $(TargetName) to ImportText to solve my issue. However, we will leave those values as they are.
Linker / General Output File
This is how I had the output file setup:
Notice that I had overridden the output target name as ImportText. This was over 10 years ago and I did not have as much experience.
General / Target Name
So all I had to do was make the same adjustment here:
Now it compiles file.
This kind of errors typically arise when upgrading old project to new version of Visual Studio (like in your case to VS2010) and also if project settings may have been manually changed (for example changing executable name). We know VS2010 uses these macros $(ProjectName) $(TargetName) $(OutDir) $(TargetExt) to control release/debug outputs but it is often mystery where to change them. We than typical resort to changing the name of output files directly through Project >> Properties. This means we now have to change the output files separately for debug and release build and if there was any dependencies, we will get error like This may cause your project to build incorrectly..
These macros/properties are VS2010 defaults but you can set them yourself in .vcproj files by editing it in notepad. Note search first for the property in the .vcproj file first, if its there than change its value, if not define it like below.
<PropertyGroup Label="My Values">
<ProjectName>New_Project_Name</ProjectName>
</PropertyGroup>
Above I have defined a new <property group> to keep these values but you can define them anywhere. I define this at the top of the file right after debug/release configuration group so its visible everywhere. Make sure your project properties are setup properly to use them correctly (they should be what is VS2010 default settings). If you have changed them you should copy it from new test project. You can of course add the other Macros you want to set values for in the above group as well.
You can also verify the new values of this macros through project properties. For example click in Configuration Properties >> General and than in 'Target Name' box. Select edit. It will bring up a dialog box with the button 'MACROS >>'. Click that and it will show you what the value of each macro is. It should correctly reflect the new values that you set in .vcproj file.
Just as Hans Passant posted, you need to modify the TargetName property manually. This is different between VS2005/2008 and VS2010. Please refer to http://social.msdn.microsoft.com/Forums/en-US/vcprerelease/thread/3c03e730-6a0e-4ee4-a0d6-6a5c3ce4343c