I'm just starting to code C++ with the VS Code.
Is it possible to set default configurations (json files) for each project?
Right now I have to manually create these files and configure them for each program.
Thanks, Roie
It seems to be not possible currently. You can monitor this issue from the vscode Github: Shared configuration (tasks/settings) #1435
Global tasks in a task.json file are still on the agenda (to get
parity with launch.json). However it is a matter of priorities when
they will come. (Oct 26, 2018)
So you would have to build something yourself like a python or bash script that automatically generates the json files for you.
Related
I am trying to build a large C++ framework in VSCode using CMakeTools and C/C++ Extensions in Visual Studio Code. I am browsing stackoverflow/github issues/any google suggestion and it looks like I am not the first person to encounter this, but I can not figure out for the life of me what am I doing wrong.
Here is the problem. I want to setup VSCode in a way to be able to build the framework (it is C++) right from VSCode using the built-in tools/extensions. Here is the process I was using up until now (in standard terminal in linux) and it also works in terminal run in VSCode:
cd /path-to-project-main-folder
source scripts/env.sh
cmake .
make -j 10
Now the problem is that when I set up VSCode, open the folder where the framework is, VSCode recognizes it is cmake project and gives me the opportunity to build it. Problem is that when I try to build it, it does not set up the environment first and therefore uses wrong cmake (not the sourced one but the default one build in server) and also wrong libraries and some of them are not even recognized.
The problem is in the first line:
source scripts/env.sh
where the environment variables are set and also PATHs to some libraries and programs. This line is not ran by VSCode before cmake and build.
Does anyone know a solution on how to configure CMakeTools extension to run:
source scripts/env.sh
line before running cmake and then make?
Thank you
I was looking into some solutions using tasks.json, settings.json files or creating my own kit. But no solution worked for me or I did not completely undestood the solution:
https://github.com/microsoft/vscode-cmake-tools/blob/HEAD/docs/tasks.md
https://github.com/microsoft/vscode-cmake-tools/issues/2243
https://github.com/microsoft/vscode-cmake-tools/pull/995
VSCode: Set environment variables via script
and man pages of CMakeTools, VSCode,...
VScode remote development: How can I run a build task to source environment variables before running the real build task? ---> but I use cmake
VSCode, how to source environment variable files like setup.bash?
On a project I am working on, I am maintaining some Feature Tests written in SpecFlow. Our team started using Visual Studio 2017 about a year ago, and we finally got around to doing some upkeep on our tests!
Our tests for the project I'm working on were originally written in SpecFlow 2.3.2, and were last updated in Visual Studio 2015.
The SpecFlowSingleFileGenerator is known to not work on VS 2017, so I spent the better part of yesterday changing our suite to use the MSBuildSingleFileGenerator instead as detailed in this article in SpecFlow's official documentation
Problem:
Locally, I can build my solution, including the Feature Test project just fine.
However, I keep getting the following error when I try to build the project on our build server:
[exec] C:\CheckoutDirectory\My Awesome Project\packages\SpecFlow.Tools.MsBuild.Generation.2.3.2\build\SpecFlow.Tools.MsBuild.Generation.targets(45,5):
error MSB4036: The "GenerateAll" task was not found.
Check the following:
1.) The name of the task in the project file is the same as the name of the task class.
2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface.
3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin" directory. [C:\CheckoutDirectory\My Awesome Project\AwesomeProject.FeatureTest\AwesomeProject.FeatureTest.csproj]
I should point out that our team has no experience with writing MS Build tasks, as hitherto we haven't needed to; we use NAnt build scripts on TeamCity to manage our build work. It's clear that error message would be helpful...if we knew literally anything about it.
Now, normally the correct answer would be: Google it. I did that, and this specific error has no pertinent results.
Additionally, this is blocking my team, since we need our build to work. I don't have the time to do the research and education necessary to properly understand how MS Build technology works. That wil have to come later.
Question:
Bearing in mind that SpecFlow has broken our process, and our team's lack of knowledge about the MS Build system: I need to know how to get around the "GenerateAll" task was not found error. What do I do to get around it?
Secondary Question:
I'm also open to lateral thinking. Is there some way to hack either VS 2017 or SpecFlow to make the SpecFlowSingleFileGenerator "compatible" with each other? The objective here is NOT to avoid making changes, but to control the changes. I need a path towards transitioning from the old file generator to the MS build generation system.
Additional Information:
So, I did some digging, and I found a place where "GenerateAll" is being called in the SpecFlow.Tools.MsBuild.Generation.targets file:
<Target Name="UpdateFeatureFilesInProject"
DependsOnTargets="BeforeUpdateFeatureFilesInProject"
Inputs="#(SpecFlowFeatureFiles)" Outputs="#(SpecFlowFeatureFiles->'%(RelativeDir)\%(Filename).feature.cs')">
<GenerateAll
ShowTrace="$(ShowTrace)"
BuildServerMode="$(BuildServerMode)"
OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
ProjectPath="$(MSBuildProjectFullPath)"
ForceGeneration="$(ForceGeneration)"
VerboseOutput="$(VerboseOutput)"
DebugTask="$(SpecFlow_DebugMSBuildTask)"
>
<Output TaskParameter="GeneratedFiles" ItemName="SpecFlowGeneratedFiles" />
</GenerateAll>
</Target>
Because I've confirmed that this is being copied out to the build server, the situation is yet more mysterious. It appears that the NuGet package is being pulled down faithfully. Therefore, I can't figure out why my local copy is behaving differently than the copy on the build server.
I am not sure where you found this statement:
The SpecFlowSingleFileGenerator is known to not work on VS 2017
The SpecFlowSingleFileGenerator is working in VS2015, VS2017 and VS2019. We see it as a legacy feature, but it's still there. Since some weeks it is disabled by default, but you can enable it in the options.
It works for SpecFlow >= 2.3.2 and 2.4. For SpecFlow 3 you have to use the MSBuild integration. There are some problems with older versions of SpecFlow, but with them it can also work. It depends on your setup.
About your MSBuild error:
The MSBuild Task for SpecFlow < 3.0 is in the specflow.exe. Is it on your build server?
It is part of the SpecFlow NuGet packages. Normally you get this kind of error if MSBuild can't find the assembly where the task is.
For "debugging" problems with MSBuild, I can highly recommend to use the MSBuild Structured Log Viewer (http://msbuildlog.com/). With it, it makes it easy so see what is happening in your build.
We have an example for MSBuild Code- Behind- Generation with SpecFlow 2.3.2 here: https://github.com/techtalk/SpecFlow-Examples/tree/master/MSBuild/OldCSProj_SpecFlow232
You could compare your project with this example.
Full disclosure: I am one of the maintainers of SpecFlow.
In the same spirit as the question Can I download the Visual C++ Command Line Compiler without Visual Studio? I would like to see if it is easy to bundle the appropriate part of Visual Studio to build Universal App written in C++. Following the answer by #Alek to the aforementioned question, I managed to create an archive where I can basically unzip and use. But this is for traditional desktop (I would say, command-line) programs. I tried to do similar thing for Universal App and there are a couple of issues
The official way (i.e. what Visual Studio does under the hood) is to use MSBuild. Unfortunately, I do not know what are and how to get all of its dependencies. It seems to require significant configuration effort as well.
There is no documentation on how to build resources (e.g. generate C++ source and headers from XAML), how to generate the .appx. If possible, a Makefile template is very much appreciated.
The reason to ask for this is because Visual Studio failed me so many times. For instance, the November Update messed up my entire system; the SDK installer fail at 96% and rolled back. Previously, the upgrade to VS2015 (from 2013) also messed me up entirely. It seems that the only solution to these problems is complete uninstall. Having a portable archive where I can just unzip and restore my production environment back to health is something I would say extremely desirable.
Note: I do not care about the IDE. I only need the ability to build apps from source code on the command prompt.
I'm working on a Django (1.8.6) project and using Visual Studio Online's GIT source control. I am building the application successfully in my local environment and push the changes to the VSO. However, whenever I try to build the application on VSO to be able to benefit from "Continuous Integration" as a next step (will try to deploy Azure), it fails by giving the error below:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Python
Tools\Microsoft.PythonTools.Web.targets (235, 5) The environment 'env
(Python 3.4) (unavailable)' is not available. Check your project
configuration and try again.
Unexpected exit code received from msbuild.exe: 1
My build definition on VSO:
Build Definition Screenshot
Python Version: 3.4.3
VS Version: 2015
Any suggestions regarding to my case is highly appreciated.
This is a known issue for PTVS. MS is still working on it. Refer to this thread for details: https://github.com/Microsoft/PTVS/issues/128
There is a workaround in that thread you may use, I quote it here. The second link is unavailabe now, but the first one still works.
For deployment via PowerShell, I found this, which looks correct
AFAIK.
http://www.kenneth-truyers.net/2014/02/06/deploying-cloud-services-to-azure-with-powershell/
You can also use the Python Azure SDK to deploy, but that's not as
well documented. This is what this test does:
https://github.com/Azure/azure-sdk-for-python/blob/master/tests/test_servicemanagementservice.py#L940
Both of these assume that you are able to create the .cspkg, as that's
the file you have to upload to blob storage.
[edit] Sorry, I out thought myself. I was using a .bat file to set environment variables that wasn't set up properly. When I went to a straight VS2005 command prompt, the configure ran fine. Sorry for the noise.[/edit]
I'm trying to compile qt-everywhere-opensource for embedded. I'm using MSVC2005. However, I guess I am confused on the process. I am getting compiler errors during the configure step. I thought the configure step was just trying to generate the needed makefiles, so I'm not sure what it is trying to compile.
I expected to modify the mkspec, but I'm not sure if during configure I should point to windows headers or sdk headers. I know during the build phase I should point to sdk headers, but I'm not getting that far.
I can change the errors by modifying INCPATH, there's also a QMAKE_INCDIR that seems to have an effect. It occurred to me that since I pulled the source, maybe configure needs to build the compiler tools, in which case I should point to MSVC headers. I also tried downloading the SDK and adding the path to it's bin folder to my path ahead of the -everywhere- source, but that didn't fix the problem and I don't want to jack up my system too much testing things.
Hope someone out there can help!
When you install Qt from source under Win32, you must:
Extend the PATH variable to include $(QTDIR)\bin, where $(QTDIR) is the directory where you installed Qt.
Open a Visual Studio command prompt in $(QTDIR); a plain old Windows command prompt won't do (unless you run vcvars.bat to load Visual Studio's environment variables; but opening a Visual Studio command prompt directly is better).
At this point, configure should run properly, after which you can run nmake.
I suggest that you clear your previous installation attempts from your system before you try these steps.