I have a C++ project in Visual Studio 2017, which I built an executable file from, using the answer from this question found on MSDN , the .exe was built successfully, but when I copy this file to another PC and try to launch it, it returns me an error message, which says that launching of this app is impossible, because libcurl.dll is absent, what should be done, for avoiding this problem ?
Here's the preset which I'm using for .exe creation
P.S.
If it is of any help, when I created the project, I've chosen Empty Visual C++ Project.
My project was working fine before I updated to the new release of VS 2017. After updating, my solutions opens but wont build and when I try to build, it says that the version of visual studio are not compatible.
what can I do? Or does anyone know how to uninstall the update so i can get my solution working again
Error message
A Project with an output type of class library cannot be started directly. In order to debug this project, add an executable project to this solution which references the library project. Set the executable project as the startup project,.
I have a VS 2015 C++ project on a remote directory that I want to share between 2 computers. On one computer it loads fine (it has Microsoft Visual Studio Community 2015 Version 14.0.25431.01 Update 3 Microsoft .NET Framework Version 4.6.01055) on the other computer it fails to load (it also has Microsoft Visual Studio Community 2015 Version 14.0.25431.01 Update 3 Microsoft .NET Framework
Version 4.6.01055). When it fails to load I get the (not very informative message)
TargetImager.vcxproj: The application which this project type is based on
was not found. Please try this link for further information
[The link is completely useless!]
I opened the project file in the solution (can't remember how I managed to do this) and it presents a number of warnings eg.
Severity Code Description Project File Line Suppression State
Warning The element 'PropertyGroup' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003' has invalid child element 'PlatformToolSet' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003'. List of possible elements expected: 'Property, VisualStudioVersion, MinimumVisualStudioVersion, AdditionalFileItemNames, AllowUnsafeBlocks, AppConfigForCompiler, ApplicationIcon, ApplicationRevision, ApplicationVersion, AppDesignerFolder, AspNetConfiguration, AssemblyKeyContainerName, AssemblyKeyProviderName, AssemblyName, AssemblyOriginatorKeyFile, AssemblyOriginatorKeyFileType, AssemblyOriginatorKeyMode, AssemblyType, AutoGenerateBindingRedirects, AutorunEnabled, BaseAddress, BootstrapperComponentsLocation, BootstrapperComponentsUrl, BootstrapperEnabled, CharacterSet, CheckForOverflowUnderflow, CLRSupport, UseDebugLibraries, CodePage, Configuration, ConfigurationName, ConfigurationOverrideFile, CreateDesktopShortcut, CreateWebPageOnPublish, CurrentSolutionConfigurationContents, DebugSecurityZoneURL, DebugSymbols, DebugType, DefaultClientScript, DefaultHTMLPageLayout, DefaultTargetSchema, DefineConstants, DefineDebug, DefineTrace, DelaySign, DisableLangXtns, DisallowUrlActivation, CodeAnalysisAdditionalOptions, CodeAnalysisApplyLogFileXsl, .... Miscellaneous Files H:\CodeProjects\QTProjects\TargetImager\TargetImager.vcxproj 20
Here is the section of the project file XML
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<PlatformToolSet>v140</PlatformToolSet>
It doesn't like this PlatformToolSet setting for instance. I don't get it because it is a setting in the property pages on VS2015 that can be selected. I anyway changed this property clicked apply then changed it back clicked apply. It is still there in the project file as before with same error message, I also changed the setting to v140_xp just to verify that it was seeing the new property which it was.
The story is that I was working on one computer with VS 2015, then I wanted to run something on another remote computer, however by then VS 2015 was replaced with VS 2017 and I installed VS 2017 on the remote. I built the project on VS2017 but then went back to the local PC with VS2015 to do some QT stuff (QT plugin is not yet available on VS2017). This was OK but then it refused to load on the remote VS2017 PC. So I uninstalled VS2017 and replaced it with VS2015, the project still doesn't load on the remote PC with VS2015.
Maybe somehow I have a VS 2017 project that for some reason loads on one computer with VS2015 and not the other, hence the settings that VS 2015 doesn't like.
So I try to create a new QT GUI project (I installed QtVsTools extension) on the remote machine that has problems with my project file. And now I get an error (the same error also occurs with a new win32 console application)
.../TarImager.vcxproj cannot be opened because its project type (.vcxproj) is not
supported by this version of the application.
To open it please use a version of the project that supports it.
As far as I know .vcxproj has been supported since MS VS 2010
Any idea how I can debug this?
The visual studio install had become corrupted, I repaired the installation then was able to create projects again. If you get weird project loading errors, then maybe your VS install is messed up.
I am observing a strange behaviour with Visual Studio 2008 when I try to debug an exe remotely.
I have a solution that includes multiple projects. Thereby, each project is compiled into a lib and linked into my main project (the project that starts when hitting the run button). Visual Studio is configured to generate a pdb file that is named exactly like my exe file. Additionally, VS generates a vc90.pdb file for each project.
Now, I can debug my exe locally when I start it from Visual Studio or when I attach Visual Studio to a locally running process of my exe. But when I run my exe on a different machine, VS shows a strange behaviour. In this case, Visual Studio correctly stops at the breakpoints in all projects except for the main project. For each breakpoint in the main project, VS says that it could not load the symbols for the document. However, the modules view shows that VS loaded the correct pdb file.
Does anyone have an idea what is different between a remotely debugged application and a locally attached debugger. Especially because the main project is the only one that causes a problem...
My environment:
Visual Studio 2008 SP1
Host machine: Windows 7 64-bit
Remote machine: Windows XP 32-bit
I figured out that I missed a setting for the main project that was done for all other projects. I had to set "Project -> Properties -> C/C++ -> General -> Debug Information Format" to "Program Database (/Zi)".
I am using Microsoft Visual Studio 2010. When I am building my application in Debug mode, it is producing an EXE file (like it is supposed to be doing). But then (which is very surprising for me), when I change the mode from Debug to the Release mode, the compiler builds the application as a .DLL file?
I have only very recently started to use Visual Studio 2010, so don't know my way around it yet. How do I fix this so that when it is compiling in Release mode, to build the application as an .exe file ?
Set your project type to Windows Application.
In the IDE, right click on your project, and select Properties.
Configuration Properties->General->Configuration Type set to 'Application (.exe)'
In project options you should be able to choose whether you're building a .DLL or .EXE. I thought these were the same for all configurations, but you can check to see for yourself.