I have a library that is used for multiple different projects that use different chip architectures (i.e. atxmega32, atxmega64, atxmega128). Within Atmel Studio 7, I can change the Current Device of the library to be associated with any of these chips to build the specific project, but I do not know how to do this without the IDE.
I am hoping to have the single instance of the library, but build it for a specified architecture in the command prompt (doing this if possible since it seems simple: https://microchip.my.site.com/s/article/Building-an-Atmel-Studio-solution-via-commandline). I thought this might need to happen through using the /projectconfig <projectconfig_file> but I do not know how to use/setup the projectconfig file to do that.
The ultimate end goal is to have a Docker container that will be able to run a build without accessing to the IDE.
Related
I am trying to simply deploy an OpenGL, C++ application from one computer to another. The app was written using Visual Studio 2017 Community. The first computer has VS installed, the second does not.
The computers have Intel Core i7-8550U CPU and Intel Atom x5-Z8350 CPU, respectively. Both are running Windows 10 Home.
The VS project started as an empty project to which I added everything.
I have copied the release, x64 application .exe file and the one .dll file necessary to the project development to a single directory on the second computer.
Microsoft instructions for local deployment say “Local deployment, in which you copy particular Visual C++ DLLs from your Visual Studio installation—typically in \Program Files (x86)\Microsoft Visual Studio version\VC\Redist\platform\library\—and install them on target computers in the same folder as the application executable. You can use this deployment method to enable installation by users who don't have administrator rights, or for applications that can be run from a network share.”
Nothing I can see or find to set in VS tells me what .dll files are being used by the application I developed and run on the first computer. There is a VS output window that shows a number of .dll files, but those are in c:\windows\system32.
From the reference in the Microsoft instructions regarding the MSVC DLLs in \Program Files (x86)\Microsoft Visual Studio version\VC\Redist\platform\library\, I looked in ..\VC\Redist\MSVC\14.16.27012\x64 on the first computer and found these folders:
I have copied the DLLs from the .CRT directory and the .MFC directory to the second computer to no avail.
When I try to run the application on the second computer it displays the message “Failed to create GLFW window”, which is in the code I wrote as shown here:
It would seem that there must be a straightforward way to do this. I have seen reference to an old Microsoft application (I think), depends.exe, which provides the a list of the DLLs required, but it is no longer deployed with Windows systems.
missing DLL or RTL
causes crash or even no error but just instant closing your app (that is what missing or miss-matching MSVCPP RTL is doing or was at some point).
As the RTL libs are changing all the time (IIRC once in a year) there are a lot of versions already so good luck using MSVCPP apps on fresh OS computers. In order to use some app you usually need to find out which version of RTL it needs which they usually do not report so you will end up with installing all of them you get hands on ...
There is a way around this problem just enable your compiler/linker to link all the stuff it needs directly into exe file instead of using RTL DLLs. However I do not code in MSVCPP and from what I heard MS removed this option from their environment (other compilers I use still have it)
Your error message indicates your App run as should and is not missing anything.
The problem is on GL side. Windows 10 is usually forcing wrong drivers (and not just for gfx cards). The goto case is enforcing (most likely intentionaly) buggy MS drivers (where GL is bugged and DX more or less works) instead of vendor provided. To remedy this (check the driver manufactor and if not what it should be) download&install correct driver from your gfx Vendor site Do not use Windows Driver service for gfx cards !!!
You can use DUMPBIN /DEPENDENTS EXENAME to get a list of bound DLLs. Mind you this only lists DLLs with import table entries, if you're instantiating COM objects this won't help at all.
My guess is you're probably missing the opengl driver/dll on the target system.
ed: actually I'm going to narrow that down to missing the driver, since if you were missing the DLL you'd have gotten an an error on load. The fact you're able to call the function means you bound to it, but that you're only getting failures when it tries to call the driver. Try calling something benign that queries for driver or device info, like a version or string. If that fails you know the driver is missing.
I am creating an application that requires a Ximea camera and a sensor which is connected to a driver. Both are C++ compatible. The problem is that the Ximea camera only builds in x86 on Visual Studio and the sensor builds on x64. I would like to run both from the same project, and I believe that I need to use MSBuild or some sort of Batch Build to configure both so that they can both run at the same time. I essentially want to take images from the camera to steer the sensor, so they both need to be running at the same time.
Here is a link to the API I am using for the camera.
(This is my first time working heavily in C++ so any advice/references/resources would be great!)
I would like to run both from the same project, and I believe that I
need to use MSBuild or some sort of Batch Build to configure both so
that they can both run at the same time.
Run and build means different things, you can use msbuild or batch scripts to build Ximea camera project in X86 and the sensor project in X64 when you build the whole solution.
In VS you can right-click Solution in Solution Explorer=>Configuration Manager to control this behavior. See:
Then when you choose Solution Platform x86, it actually builds the project A and B in X64, and C in X86. This is what msbuild can do for you. But I can't make sure if there will be compatibility issue when you run it.
I've created an app with a C++ backend and a HTML-based frontend. I've also created a setup file by using Inno setup including all the needed DLLs and other files. I've tested in several different machines, virtual and real ones, in order to check its consistency. I've also given it to different people as well to test it.
In one of these cases, however, the app crashed. I also have created a C++ logger, but unfortunately didn't give any additional valuable info.
I assumed that it may have to do with Windows permission issues, so I created different C++ executables by changing the manifest file in Visual Studio, but no luck.
As far as I know, in order to deal with these kind of situations, one either uses the remote debugger of Visual Studio on the host machine, or use Windbg on the target machine, but these two ways require either network access to the target machine or knowledge of Windows debugging from the end user.
I'd like to know what one can do if there is no network access and the end user is not capable of debugging even by following instructions. Is there a way, either by C++ or through Windows, to generate a crash dump file that can be used afterwards for debugging?
I made a program in Microsoft Visual Studio C++ and used the SFML for this. I included the correct .dll-Files, that the program needed, and copied them into the "Release"-Folder. It worked. The entire program worked flawless on my computer, but as soon as I tried to run it on another computer, it said: Missing "MSVCP140.dll" and Missing "VCRUNTIME140.dll.
I searched for a solution of this program, and always heared "Go to Project > Project Settings > C/C++ > Code generation > Runtime libraries > switch to Multi-Threaded (/MT). I compiled the project with this settings, and the executable increased in size, which they said is normal, because there are no supporting .dll-Files anymore.
But as I tried it again, with the new .exe, it gave me the exact same Error-Messages. Are there any other possibilities to solve this WITHOUT installing some -dll-Files onto the computer?
This is covered on MSDN in some detail. See Deployment in Visual C++
You really have three choices:
Use the "centralized" versions of the DLLs. For this you should have a setup program that runs the VCREDIST_*.EXE packages for VS 2015 or if using a MSI-based setup you can use the MSM files provided.
Copy the required DLLs as part of your program. This means your installer or zip file or whatever that has the EXE includes the DLLs it needs too. This is the best choice if you want "copy and run" style deployment, but remember that all security servicing of the DLL is now your problem.
Use static linking. From a security perspective this is the least desired solution, and really should only be used in the specific cases of writing an installer--i.e. the program that installs an app has to run in the first place.
You have not specified which version of Windows is running on your target machine. VS 2015 does not support Windows 7 RTM as it's out of support, but it does support Windows 7 Service Pack 1 along with Windows Vista Service Pack 2, Windows 8.x, and Windows 10.
While we are on the subject note that Windows 8.0 is also out of support. Those users need to upgrade to Windows 8.1 Update or Windows 10.
I created application which uses wxWidgets library using visual studio 2008. Now I would like to create version which may be run on other machine.
Because right now when I want to run It on another machine there is an error:
the application failed to start because its side-by-side configuration is incorrect.
What can I do to make It work ?
The Event Viewer should have a record showing what DLL was being searched for, what version of that DLL if found in the SxS cache, and what version it was looking for but couldn't find. You'll then want to (for example) include the correct version of that DLL to be installed with your program. Alternatively, just link to virtually everything statically -- it'll make your executable a lot bigger, but eliminate a lot of problems like this relatively painlessly.