I'm trying to set some environment variables in my visual studio project going to Project Properties > Debug, and supposedly there should appear an option to set Environment variables there, but I couldn't find it, I found several images where this option does appear but it probably is from another VS version.
What is the way to set them in Visual Studio 2015?
Thank you in advance.
Related
so I messed up some project properties (values in VC++ Directories and so on) and dont know how to go back. Is there any way to get back to default properties (same when I installed visual studio). ReInstallation did not help.
I have made a few change in simplescalar sim-fast.c, but I don't able to debug this change in visual studio 2019.
are there any way to do this?
Thanks.
From your comment, it seems you are trying to debug an opened file/folder right?
Visual Studio is not supported to build/debug a file/folder, at least it is not possible for a single file. For folders, some may be supported, but need to have some files been included, such as a .sln file, a .vcxproj file and so on. Instead, Visual Studio supports to build/debug a project/solution.
I'm not familiar with simplescalar, I guess it is not possible to open it as a project/solution in Visual Studio to build and debug though. You can have a try open it as a project, and perhaps consider using other editor tools, if it can't be opened as a project, for example Visual Studio Code.
We are using a commercial software that has its own scripting language with which you can customize the product. It is very tedious to write code in it without any help from an IDE and it has its own compiler.
Is it possible to use Visual Studio and create an environment for me to write scripts in this language and get the help of intellisense and syntax highlightning and other good things you find in an IDE? Ideally I would like to bind a button in VS to launch the external compiler and compile the code so I don't have to switch windows all the time as well.
If this is possible is it a very hard thing to accomplish?
Yes, this is certainly possible. You need to create a Visual Studio Shell add-in with custom language services and text editors. You need to install the appropriate Visual Studio SDK and then you'd continue to:
Create a custom Editor and/or designer
Add a language service
Add Project and Item templates
You're allowed to ship Visual Studio Isolated Shell with your application (license required and there are some limitations) so that your users don't need to have Visual Studio Professional installed.
There are a number of open-source projects that provide a custom editor, language services etc in Visual Studio, these could provide a nice place to research how things are done, next to teh Visual Studio SDK documentation:
PyTools, which is a Visual Studio editor for IronPython
Phalanger, which contains a Visual Studio editor for PHP
PoShTools, a Visual Studio service for PowerShell editing right inside Visual Studio
You'll probably want to dig into MsBuild as well, since Visual Studio will expect you to create a project file if you want to edit a collection of files and compile them. MsBuild could in turn call your own compiler, like it calls csc to compile C# code for example.
Creating Project Types
Background
I am open sourcing a few old Visual Studio applications I created a while back. I have created new solutions using my new VS2012 environment for them and have gotten the projects set up as git repositories. I got everything working fine in Visual Studio 2012 with no changes to the source code, all I needed to do was make sure I was linking the proper libraries in the new project configurations.
I would like to configure these projects as to have maximum compatibility for others downloading the project from Github. On this machine I have VS2010 installed alongside the latest VS2012 version. After I got everything working right for both of the projects in VS2012, I tried to open them up in VS2010.
When I tried to build I got a single error:
Specified platform toolset (v110) is not installed or invalid.
Please make sure that a supported PlatformToolset value is selected.
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets 518
What I Tried
So I opened up the properties for the project, went to Configuration Options --> General and the Platform Toolset was indeed set to Visual Studio 2012 (v110). This input is a drop down box and the v110 value is not listed, instead I get two choices:
v100
v90
These correspond to VS2010 and VS2008 respectively. If I change the value to v100 and rebuild I get no errors and my program runs just fine in my Visual Studio 2010 environment.
When I open the project back up in Visual Studio 2012, if tells me that I have an old project file and asks if I want to upgrade, I say yes and it upgrades. I rebuild and run to make sure everything is still working. When I open the configuration options in VS2012 the Platform Toolset is set back to `Visual Studio 2012 (v110) but clicking the drop down input there are several more choices listed:
Visual Studio 2012 (v110)
v110_wp80
Visual Studio 2012 - Windows XP (v110_xp)
Visual Studio 2010 (v100)
Visual Studio 2008 (v90)
‹inherit from parent or project defaults›
My Questions
This has led me to several questions. I am going to pose them all. It would be nice to get as much information as I can, but a good answer to just one of them would probably solve my problem.
If I'm not using features specific to newer versions of Visual Studio, is it possible to set up a solution which can be opened and run without modification in as many versions as possible (ie. 2008, 2010, or 2012)? If so, how?
If I set the Platform Toolset to v90 (VS2008) from within Visual Studio 2012, and it's able to build and run, does this mean that it will build and run for users with VS2012, VS2010, and VS2008?
What exactly does the <inherit for parent or project defaults> option do? What would the project defaults be set up as? Can this be used to tell Visual Studio to try to using whichever installed Platform Toolset will work.
Are there any other options besides Platform Toolset in Visual Studio that I can set to increase compatibility with others' development environments?
This is a somewhat tricky situation. One of the underlying problems here is that VS2010 and VS2012 use MSBuild to build C++ projects, but VS2008 farmed it out to VCBuild instead. You can see this by comparing the project files. VS2010/VS2012 use .vcxproj, while VS2008 uses .vcproj.
If I'm not using features specific to newer versions of Visual Studio,
is it possible to set up a solution which can be opened and run
without modification in as many versions as possible (ie. 2008, 2010,
or 2012)? If so, how?
For maximum compatibility, you want to target the lowest common denominator (i.e. vc90 in this case). Note that when you do the upgrade, the solution file and project files get upgraded to the latest version, which may break compatibility with older versions of Visual Studio.
If I set the Platform Toolset to v90 (VS2008) from within Visual
Studio 2012, and it's able to build and run, does this mean that it
will build and run for users with VS2012, VS2010, and VS2008?
Not really, due to the .vcxproj / .vcproj conflict stated above.
For example, I currently have a set of .vcxproj files and a solution designed for VS2010. I use VS2012 as my IDE, so when I open the VS2010 solution in VS2012, I choose to NOT upgrade it and simply open it as is. VS2012 and beyond should be backwards compatible back to VS2010 as far as project files go.
For maximum compatibility in development environments, my recommendation would be use VS2010's solution as the baseline, targeting v100. Developers can use any version newer than that and it should all work together gracefully.
I have a csproj file which references a shared MSBuild script with an <Import> directive. I have noticed that when I change the shared script, I need to close and reopen Visual Studio before it notices the change - a build within Visual Studio notices changes to the csproj file but not the shared file.
This doesn't happen when I build the project with MSBuild from the command line. Is Visual Studio caching the imported script? If so, why? And how can I turn off this behaviour which makes authoring build scripts hard / impossible using Visual Studio?
Thanks!
Instead of closing and re-opening Visual Studio have you tried, unloading and reloading the project (.csproj) which imports the shared script? You can do this from the Solution Explorer in Visual Stduio by right clicking on the loaded project and selecting unload and then on the unloaded project and picking load.
In my experience, Visual Studio 2015 behaves better than Visual Studio 2008.
VS picks up changes from imported files in most cases, at least for C# projects.
YMMV for other project types, though.
While the solution explorer doesn't reflect changes, the build uses the updated version of the import file.
So, the solution may be to use a more recent version of Visual Studio.