Is there a file somewhere that I can use to do massive changes to the context menu in an easier fashion?
The GUI:
gives me no way to move a command from one menu to another, nor does it let me see what the command actually is (in order to add that same exact command to another menu), thus I don't have much to work with.
And thus I am seeking a file (or a gigantic registry key? ugh.) that I can edit somewhere else where I have more powerful tools. (my VS version is Enterprise 2017 if that matters)
You can find the defaults at C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Profiles, with a general settings and some language-specific overrides. There's an additional override in IDE\VC\Profiles as well.
In my case, I wanted to move 'Start new instance" on a Project into the top-level context menu. So I:
Made a copy of CurrentSettings.vssettings
Added a new command where I wanted it (via the Tools > Customize... GUI)
Found the command I wanted to clone and moved it up one
Closed VS (it saves on exit)
Compared the two files to find the diffs (use your favorite tool.) You'll find them under Category[#name="Environment_CommandBars"]\CommandBars\UserCustomizations as add remove and modify entries
Took the Cmd attribute from the moved entry and pasted it over the added one (it was Cmd="{1496A755-94DE-11D0-8C3F-00C04FC2AAE2}:00000164" for me, to save interested parties a few steps)
Undid the move to retain only the added entry
I wasn't able to find a command entry for this anywhere in the defaults, so had to figure it out the hard way.
I've recently encountered Property Sheets in Visual Studio, which provide a way to define user defined $(MACRO)s for a project. They're not what I really want but are the closest I can find in VS so far.
However, under the property manager (View -> Other Windows -> Property Manager) it doesn't seem to be possible to get the User Macros section of the configuration editor to show up unless you edit a specific configuration/platform combo, like Debug | Win32.
If you have quite a few configurations and want to (say) set a macro to the same value for all configurations on the same platform, this gets cumbersome fast.
When editing project properties normally you can select "All Configurations" and/or "All Platforms" to have changes copied to sub-sections. This isn't available when editing a property sheet.
Is there any way to set values in a property sheet for multiple configurations/platforms at once? Consider, for example, that you want to set a macro POSTGRES_INSTALL to %PROGRAMFILES%\PostgreSQL\9.3 for x64 targets and %PROGRAMFILES(x86)%\PostgreSQL\9.3 for x86 targets, is there any way to do that for multiple targets (Debug, Release, SomeCustomTarget) at the same time?
How property sheets work
Property sheets are simple lists of properties. Entries aren't per-configuration or per-platform.
If you add a property sheet to the top level of a project, it's added to all configuration/platform combinations underneath, as if you individually added that property sheet file to each configuration yourself.
All properties are therefore visible across all configuration/platform variants.
This means you can also do things like have one sheet for all your x86 configurations and a different sheet for all your x64 configurations, e.g. for build paths. That way all the rest of your properties in your code can just use $(MYLIB_INCLUDE) without worrying about whether it's a 32- or 64-bit build.
You can usefully combine per-configuration/platform and global property sheets, too, a property sheet can reference one further down the list. (Order is significant, and they seem to be read from bottom to top according to the UI).
You can check what the final values of properties are by going to edit a property in the main project properties page, and tabbing open the "Macros>" tab. This is useful when debugging ordering issues with one user macro referencing another from a different sheet.
Example of usage, with code
As an example, which you can download from pg_sysdatetime on github here, I created three property sheets:
pg_sysdatetime.props is the master sheet that users can edit to change paths. It defines PGBASEDIR_x86 and PGBASEDIR_x64 macros with the paths to the 32-bit and 64-bit PostgreSQL installs on the system.
pg_sysdatetime_x86.props is a simple wrapper that defines PGBASEDIR as $(PGBASEDIR_x86).
pg_sysdatetime_x64.props does the same for $(PGBASEDIR_x64)
I added pg_sysdatetime.props to the top level of the project, so it got applied to all configuration/platform combinations.
I then added sysdatetime_x86.props to all x86 platform configurations, and sysdatetime_x64.props to all x64 platform configurations.
The properties editor looks like:
and I can see the macros properly defined when editing a property:
Now I can reference the PostgreSQL libdir, include directory, etc from anywhere in my project with simple macros like:
$(PGBASEDIR)\lib
without caring whether I'm doing a 32-bit or 64-bit build, etc etc. So I can just edit settings for "all configurations", "all platforms" and know that they'll work for everything, I don't have to individually edit each one.
It's almost like using a Makefile from 1980 ;-)
I would like to define user environment variables in a Visual Studio solution. Then I would like to use them in the project files. For example:
<ProjectReference Include="$(MyUserVar)\MyProject.csproj">
Is it possible?
This can be done in the VS property sheet.
Go to the Property Manager tab if it's not highlighted yet.
Double click on the newly created property sheet.
Go to the User Macros node and press the Add Macro button. Insert name to the value field as you'd like and set this macro as an environment variable in the build environment.
Detailed step-by-step instructions can be referred here: https://sites.google.com/site/pinyotae/Home/visual-studio-visual-c/create-user-defined-environment-variables-macros
Whenever I try to run a project on Expression Blend 4 an error always appear.
The specified solution configuration "Debug|MCD" is invalid.Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p Configuration=Debug / p:Platform="Any CPU" or leave those properties blank to use the default solution configuration )
In some forums I've read that by deleting something on the registry will solve this issue but what I want to know is if it's safe to do that or if there are other ways to solve this error.
It turns out that HP machines from the factory come with several global variables set for it’s own update software, including things such as “PCBRAND”. One of those variables are, you guessed it, PLATFORM.
In VS 2010 RC the build environment started respecting “Platform” as a compile time System variable. Therefore, because no such platform exists in your deployment configuration, it fails.
It’s a pretty simple fix, just delete the PLATFORM variable.
You need to do the following steps:
Right-mouse click "Computer"
Go to "Properties"
Click "Advanced System Settings"
Click "Environment Variables"
Under "System Variables" find "PLATFORM" and delete it.
Restart Visual Studio
Here’s hoping I saved you some time.
If you mean:
http://social.expression.microsoft.com/Forums/en/blend/thread/f664d317-2415-4369-b461-a22eb0a2f023
&
http://social.expression.microsoft.com/Forums/en-US/blend/thread/71496590-a9ec-4e3a-8353-3ced345f78dc/#18af3654-2ee7-4e61-a1e1-321d430026eb
Then yes. It's to do with HP and the way they package up the extra applications on the machine. I found that the MCD platform key was in the registry in a few places, I deleted them and then restarted and now blend builds great.
On a class library project, I set the "Start Action" on the Debug tab of the project properties to "Start external program" (NUnit in this case). I want to set an environment variable in the environment this program is started in. How do I do that? (Is it even possible?)
EDIT:
It's an environment variable that influences all .NET applications (COMplus_Version, it sets the runtime version) so setting it system wide really isn't an option.
As a workaround I just forced NUnit to start in right .NET version (2.0) by setting it in nunit.exe.config, though unfortunately this also means all my .NET 1.1 unit tests are now also run in .NET 2.0. I should probably just make a copy of the executable so it can have its own configuration file...
(I am keeping the question open (not accepting an answer) in case someone does happen to find out how (it might be useful for other purposes too after all...))
In Visual Studio 2008 and Visual Studio 2005 at least, you can specify changes to environment variables in the project settings.
Open your project. Go to Project -> Properties... Under Configuration Properties -> Debugging, edit the 'Environment' value to set environment variables.
For example, if you want to add the directory "c:\foo\bin" to the path when debugging your application, set the 'Environment' value to "PATH=%PATH%;c:\foo\bin".
In Visual Studio for Mac and C# you can use:
Environment.SetEnvironmentVariable("<Variable_name>", "<Value>");
But you will need the following namespace
using System.Collections;
you can check the full list of variables with this:
foreach (DictionaryEntry de in Environment.GetEnvironmentVariables())
Console.WriteLine(" {0} = {1}", de.Key, de.Value);
In Visual Studio 2019 right-click your project, choose Properties. In the project properties window, select the Debug tab. Then, under Environment variables change the value of your environment from Development to Production or other environments. For .Net Core and .Net 5 the property is called ASPNETCORE_ENVIRONMENT.
Visual Studio 2003 doesn't seem to allow you to set environment variables for debugging.
What I do in C/C++ is use _putenv() in main() and set any variables. Usually I surround it with a #if defined DEBUG_MODE / #endif to make sure only certain builds have it.
_putenv("MYANSWER=42");
I believe you can do the same thing with C# using os.putenv(), i.e.
os.putenv('MYANSWER', '42');
These will set the envrironment variable for that shell process only, and as such is an ephemeral setting, which is what you are looking for.
By the way, its good to use process explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx), which is a sysinternals tool. You can see what a given process' copy of the environment variables is, so you can validate that what you set is what you got.
Starting with NUnit 2.5 you can use /framework switch e.g.:
nunit-console myassembly.dll /framework:net-1.1
This is from NUnit's help pages.
If you are using VS 2019, Go to Project-> Properties->Debug. check here
Add key and value for your variables. Then it is done. Check launchSettings.json in properties folder you should see your variable there.
If you can't use bat files to set up your environment, then your only likely option is to set up a system wide environment variable. You can find these by doing
Right click "My Computer"
Select properties
Select the "advanced" tab
Click the "environment variables" button
In the "System variables" section, add the new environment variable that you desire
"Ok" all the way out to accept your changes
I don't know if you'd have to restart visual studio, but seems unlikely. HTH
Set up a batch file which you can invoke. Pass the path the batch file, and have the batch file set the environment variable and then invoke NUnit.
As environments are inherited from the parent process, you could write an add-in for Visual Studio that modifies its environment variables before you perform the start. I am not sure how easy that would be to put into your process.
In Visual Studio 2022, go to solution explorer, right click to project file. Then, click on the Debug link at the left side. Then, click on the Open debug and launch profiles UI. Then, you can add new variables into the field in Environment Variables section.
Environment Variables
In VS 2022 for .NET 5 and 6 you can set environment variables under properties of project -> Debug -> under General click on 'Open debug launch profiles UI' and scroll down to 'Environment variables'
I prefer to keep all such definitions in the make files, i.e. in the .*proj or .props - because these are under SCM.
I avoid the VS-Gui-Property-Dialogs. A lot of the config you write there goes into some .user, .suo or so, which is usually not under SCM.
E.g. in case of environment variables you could write (using a text editor) something like the following in your .vcxproj:
<PropertyGroup>
<LocalDebuggerEnvironment Condition="'$(Configuration)'=='Debug'">
ANSWER=42
RUNTIME_DIR="$(g_runtime_dir)"
COLOR=octarin
</LocalDebuggerEnvironment>
</PropertyGroup>
NOTE that you can use MSBuild Conditions and other build properties to define the environment variables.
NOTE: this works for me with VS2013 and VS2019. I think it is the same for other VS + MSBuild versions.
You can set it at Property > Configuration Properties > Debugging > Environment