I am currently using visual Studio in combination with the remote debugger to develop software on a virtual machine. Problem is that the software I develop is an extension for another program, which does not exist on my computer anymore and is now only installed on the virtual machine.
Before I did this I had the project and the other program running on my local machine and used the following code to copy the built files into the extension directory of the main program (post build event command line):
xcopy "$(ProjectDir)\SDK_5.dll" "$(TargetDir)" /y
xcopy /Y "$(TargetDir)*" "C:\ProgramData\Autodesk\Vault 2022\Extensions\MyExtension\"
I am wondering if it is possible to use the xcopy command to copy stuff on to the virtual machine or make visual studio build the files directly in the "Extensions" folder of the virtual machine.
Is it possible? I am on the same network as thevirtual machine and I'm using the machineName:port combination to connect to it if that matters.
Related
(Only to be clear, this question is regarding Intellisense only)
Here is my developing scenario:
Visual Studio 2022 (Enterprise edition, 64 bits)
C++ project (Run by SSH to a Raspberry Pi 4 - ARM64 using Ubuntu 20.04 server)
Project is a Makefile project (not CMake).
The code compiles and runs in the Raspberry Pi (via SSH), but the problem is with Visual Studio Intellisense that cannot find the OpenSSL files.
I ran the tutorial here (https://kontext.tech/article/594/microsoft-vcpkg-c-library-manager) and installed vcpkg
vcpkg install openssl:arm64-windows
and ran the instruction to integrate to Visual Studio
vcpkg integrate install
and everything seems to be installed correctly,
PS C:\vcpkg> .\vcpkg.exe integrate install
Applied user-wide integration for this vcpkg root.
CMake projects should use: "-DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake"All MSBuild C++ projects can now #include any installed libraries. Linking will be handled automatically. Installing new libraries will make them instantly available.
but as this is a Makefile project (and not CMake), it still seems to have the problem with Intellisense.
Could you please help me to determine how to make Visual Studio to finally find the OpenSSL files?
Thank you.
I made progress in solving the problem in an unexpected way. As the project built successfully in the remote machine, I ignored the Intellisense problems for a while. But one day I connected to another machine and there were no problems! Intellisense found all the files.
The machine with problems had Ubuntu 20.04 and the other one Raspbian OS. The difference was that I installed OpenSSL using apt in Ubuntu,
sudo apt -y install libssl-dev
but I compiled the OpenSSL source code in the Raspbian OS. (https://www.linuxtuto.net/blog/how-to-install-OpenSSL-3-on-Ubuntu-20-04) and (https://nextgentips.com/2022/03/23/how-to-install-openssl-3-on-ubuntu-20-04/)
So I knew the problem was due to the headers.
I compiled OpenSSL from source in Ubuntu, and it didn't work. But I had a third machine with Ubuntu 22.04 and did the same, and it worked. So I knew the exact problem: Visual Studio didn't bring the headers after an initial SSH connection was made.
Solution:
[IMPORTANT] Download OpenSSL source code using the tutorials I linked above, and compile it in your Linux machine (mine was an upgrade from 1.1.1f to 3.0.5).
Go to C:\Users[Your user]\AppData\Local\Microsoft\Linux
Depending on your Visual Studio version (mine is 2022), you will have a folder structure. Search around and you will find an XML file with your connection information (in my case, it was in User Data\3.0\store.xml)
Open the XML. You will have a list of all the SSH connections that version of Visual Studio has made to remote machines.
Check in the HeaderCache\1.0 folder. You will find folders with random numbers, and they match the connections from the XML. Identify the problematic connection.
Inside Visual Studio, delete that SSH connection. (It should also disappear from the XML, but it DOES NOT automatically delete the folder, so this is why the problem happened in the first place).
Delete the associated folder inside the HeaderCache\1.0 you found in step 4.
Recreate the SSH connection inside Visual Studio. It should appear in the XML and a new folder must be created inside HeaderCache\1.0.
Check inside the new folder. Go to the subfolder usr\include. There should be an OpenSSL folder.
Change the configuration of your solution in Visual Studio to use the new SSH connection.
Problem solved!
Edit: Sometimes you must delete your Visual Studio Configuration (inside the Configuration manager). After you delete the problematic configuration, in some cases Visual Studio still shows it inside the project properties. If that is your case, you must:
Open the Package Manager Console (Tools -> Nuget Package Manager -> Package Manager Console)
Run the command:
Get-Project -All | Foreach { $_.ConfigurationMAnager.DeleteConfigurationRow("Name of your configuration with quotes") }
And that's it!
I have a Linux project witch I developed in vim and now I'd like to go on developing it in Visual Studio with IntelliSense etc.
It's a Makefile project so I need to build it on the Linux machine.
I already created the project and created the connection and it works but I can't build because I am building with a prefix script so I open a new interactive shell with something like this
set -i
. "/tools/dist/xxxx-2010.0"/etc/profile
I don't think that visual studio can handle such thing.
Is there a way to do it?
I am calling my startprefix script with an alias then it starts the interactive shell and then I enter my make commands for usual but in visual studio it won't build it stops at t he very beginning after executing the first command (which is the startprefix alias)
And another thing is that I don't see any project files in my solution I unloaded and loaded the project but it won't get me the source files. Am I doing something wrong?
The Visual Studio C++ for Linux add-in supports MSBuild, makefile and CMake projects. If you already have the makefile then create a new Linux makefile project in VS, add in the source files and hit F5 to build.
Trying to read between the lines of your question:
C++ for Linux is optional and must be installed
thru the VS installer.
Everything, i.e editing, building, debugging, is run in VS from the
Windows host.
The source resides on the Windows host (although you can do things with shared drives if needed).
The Linux remote is just that, remote.
You might need to interact with the Linux remote to debug an
X-Windows based GUI application but console applications can be
debugged entirely on the Windows host.
If you have other commands that you need to run before and/or after the makefile then you can set these up in the VS project settings. Likewise and parameters you need to pass to make.
I've recently been busy working on making proper build scripts for a code library I've been designing, and have been stuck on getting MSBuild to properly compile for my Windows builds. What I'm trying to do is call MSBuild from a batch script without it opening the Visual Studio IDE, which it appears to constantly do if I'm not executing it from the Developer Command Prompt for Visual Studio. My script is simple enough, just calling
start C:\Program Files (x86)\...\MSBuild\15.0\Bin\MSBuild.exe <Project>.sln
Besides a few other specifiers tagged onto the end of it, that's what I'm trying to use to run my Windows builds. The issue here is that whenever this code is called outside of the VS Dev Prompt, Visual Studio itself opens, not building the code at all. I couldn't find anyone else struggling with this same issue either, as it seems to be new to the integration of MSBuild and Visual Studio. Testing with older versions of MSBuild went to show that I could build projects as I wanted to outside of the Dev Prompt. Could I be missing some environment variable supplied in the Dev Prompt that changes the executable behavior? I couldn't seem to find any executable specifiers that would change this, either.
Maybe I'm taking a completely wrong approach to this problem? My end goal is to provide consumers with a collection of build scripts, one for each platform they're targeting, so I am definitely open to other solutions.
The canonical answer:
You can use the devenv command with the /build command line option and the name of your project file.
Alternatively, you can run one of the vcvars*.bat scripts to set up the necessary environment and then use msbuild.
For more info, see https://learn.microsoft.com/en-gb/cpp/build/building-on-the-command-line.
Update: Contrary to the official advice above, this is what works on my laptop with VS2017 community edition.
Setup the environment by running the bat file that is targeted by the "developer command prompt for VS2017". (Right-click on that in the start menu, then select "Open file location" then right-click on the shortcut and select "properties". For me that is "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat".
You should call this file from your build script.
cd to your project directory and then use msbuild like this:
msbuild My-project.vcxproj /p:Configuration=Release
For some really strange reason I can use the devenv method if I open the official developer command prompt but launching devenv from another command prompt even with the environment variables set does nothing. (And I even compared the set of environment variables in both command prompts and they are equal.)
How to Run MSBuild Outside of the MSVS Dev Prompt?
If the necessary environment not be set correct, then the build command becomes " mysolution.sln". And executing it indeed starts VS. So you should run the vcvars*.bat scripts to set up the necessary environment and then use msbuild. Following is my a batch script, it has been working for some time, you can check it:
#echo OFF
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\VsDevCmd.bat"
echo "Starting Build for all Projects with proposed changes"
MSBuild.exe "C:\Users\Admin\Source\repos\MyTestProject\MyTestProject.sln"
pause
echo "All builds completed."
Here is the test sample result:
See How to create a Simple Build Script for Visual Studio from the Command Line? for more details.
I have built a visual studio c++ console application(x64 release build). The .exe file in the release folder runs fine with the required dlls.
When i try to run it on other machine it throws error
The Application was unable to start correctly (0xc000007b). Click OK to close the application
There is no x86-x64 lib mismatch issues.
In another machine it works well.I don't know whether it needs any resource to run the .exe
I have tried building the application statically still no results..
1)It is possible the new machine is missing important software like .NET framework or something similar. Please install the other frameworks and then try to run it on other machine.
2)If new machine has other OS try to run program in compatibility mode
You need the same Visual Studio redistributable .dlls on your target machine.
You'll either need to install the redistributable or install visual studio on that machine.
Also note that it makes a difference whether you're using Express or not.
So you can't develop on Visual Studio 2008 Express and then install the Visual Studio 2008 Redistributable.
I have a driver I have written in unmanaged C++ using Visual Studio 2010. When compiling the DLL on a 64-bit Windows 7 the post-build step is:
echo Copying $(TargetFileName) to the OS's 64-bit system folder ...
xcopy $(TargetPath) $(SystemRoot)\System32\. /Y /Q
However, the dll is copied to $(SystemRoot)\SysWOW64\ instead, which supposedly only happends to 32-bit assemblies.
BUT! If I copy the dll to System32 using Windows Explorer or with xcopy from a command shell the dll is correctly placed in the System32 folder. What am I doing wrong? Is it because Visual Studio is a 32-bit program and the POST-BUILD event is run in context of that 32-bit process?
Your script is being run from a 32-bit process. As a sort of band-aid solution you should be able to replace system32 with sysnative and the WOW64 layer should do the right thing.
Update: Sorry, maybe this instead: %windir%\sysnative\cmd.exe /C "xcopy ..."
The variable SystemRoot is expanded corresponding to the calling program.
Since the calling program (devenv.exe) is a 32-Bit program it is replaced with the SysWOW64.