How to include the windows runtime dll files in setup project.
without vc++ 6.0 software in the machine the project must execute.
or give me the hint how to make a the project setup(EXE) in vc++ 6.0 ,i am using create installor,
You can modify the project settings to link statically to the C runtime (I assume this is what you mean when you said windows runtime ?). The static link flags are:
MultiThreaded static linkage (/MT)
MultiThreaded debug static linkage (/MTd)
Sorry, been awhile since I used VC6.0, so I had to check the GUI. You'll find this in project settings, C++ tab, Code Generation combo box, "Use run-time library").
To add to what Cannonade has already said, if you are doing it through Visual Studio, then this can be done through Project Settings->General Page->Use MFC as a static library. This way your created exe will be ready to run on any windows box.
Related
I am working on a C++/CLI project with VS 2012 in Dynamic Library (.dll) and x64 mode.
If I switch the mode to Static Library, I get the error below.
Error 1 error C1107: could not find assembly 'mscorlib.dll': please specify the assembly search path using /AI or by setting the LIBPATH environment variable C:\Depot\Main\Current\Sln\ALibraryProject\Stdafx.cpp 1 1 ALibraryProject
I tried removing the reference to the mscorlib.dll then adding it again from:
Project > Properties > General > Common Properties
But that didn't help. As I know that VS handles the reference to the .NET assemblies, I don't want to add a disk file reference to it as it seems illogical! Did anybody face this before?
I had the same problem when converting my solution from the VS2010 compiler to VS2013 compiler.
I resolved it by changing the project settings (for the project containing the managed .cpp file that was throwing this error) as follows: In Project Settings | C/C++ | General | Additional #using Directories I added the macro $(FrameworkPathOverride). This resolves to the reference assembly directory for the version of .NET that you're targeting, which in my case is C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.1
If I switch the mode to Static Library
This is not the typical error you get when you try to build a static library with /clr in effect. I'd have to assume you've been tinkering with project settings to get rid of the inscrutable linker errors you get when you try to do this.
Core issue is that the C++/CLI build system doesn't support static libraries that contain MSIL. Managed code doesn't use a linker, binding happens at runtime. Which makes the essential difference between static libraries and DLLs disappear. So Microsoft decided to not support it because it didn't make much sense to implement it. Unfortunately they don't yell loud enough when you try to do it anyway, the linker errors you get don't give enough of a hint what you did wrong. Workarounds, like merging with ILMerge don't work either, it cannot deal with mixed-mode assemblies. Merging the native code sections and their associated relocation table entries is very untrivial.
Keep in mind that it is fine to link native static libraries. A typical C++/CLI project has only the ref class wrappers that need to be built with /clr in effect. You can glue any amount of native code from libraries into the final assembly.
I'm forced to theorize about the actual compile error, too many programmers get this error for another reason that doesn't have anything to do with building static libraries and they are harassing me in the comments.
Do beware that targeting a different version of .NET than the one you have installed on your machine is quite a hazardous affair, particularly so if you want to target 4.0 and you have 4.5.x installed. The key element in your .vcxproj file is the <TargetFrameworkVersion>. This will be missing if you started the project targeting an old .NET version, you have to insert it yourself. The IDE also doesn't support changing it if it is present, again edit by hand.
Which is enough to coax MSBuild into generating the proper compile command. You can verify if that panned-out well, look in the *.tlog subdirectory of the Debug build directory for your project. The cl.command.1.tlog file shows the options that were passed to the compiler. It should contain:
/AI"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0"
/FU"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\mscorlib.dll"
Note the subdirectory, very important that it matches your intended .NET target. v4.0 in this example. And very, very important that it does not point to c:\windows\microsoft.net, the legacy location for reference assemblies.
I have the same problem. Having a dll doesn't work, as I need to provide a native C++ wrapper for a .net object so it can fulfil a natice c++ interface - I can't use .net in a dll interface - this gives a compile error
This worked as a static library in VS 2010 (with .net 4)
Some of my executables and dlls which also have some code with /clr. They don't have an issue. I'm not trying to make a net Lbirary.
I solved it by removing dependency in old and not updated mixed lib, which was also configured only in Debug configuration, and as result, it started to get the same error as yours after I changed some code.
It was not simple to find it, because error is not clear, and the dependency was set up via "Additional Dependencies" in project settings.
Open visual studio and unload your project then Go to the project folder and open file .vcxproj . Search for tag "targetFrameworkVersion"
(if not present it means ur project is not using dot net frameworks.so no requirement of change)
Change it to required version
Save the file.
And now reload the project .
Not sure if anyone else is having this issue.
I am attempting to create a windows forms library control. I need the control to run in an x86 environment. So, the first thing I do is go into the properties of the project and switch the platform target to x86.
I try running the application and I get the lovely error message referencing the assembly I am trying to create and stating: An attempt was made to load a program with an incorrect format.
I have not added any references nor any code, just trying to create a control in x86.
I am using a windows 7 64bit machine with VS2012 trying to write the app in .NET 4.5. I have to do the project in x86 because I am using some OCX that are x86 only.
Has anyone run into this?
go into the properties of the project and switch the platform target to x86
Well, that worked. Instead of a confusing COM exception (typically "Class not registered" which has several possible reasons) you get an early .NET exception that tells you that you are using the library wrong.
To test your library project, you needed to create an EXE project that had a reference to the library project. What you forgot to do is change the Platform target setting on that EXE project. Which matters because only the EXE project can determine what the bitness for the process will be. It is the one that loads first, a library project has no say. It can only veto the choice, the BadImageFormatException is that veto.
So you have to change the Platform target setting for the EXE project to x86 as well.
I am writing an installer using wix. I have also written custom actions. But while installing the MSI the installation fails because the target system does not have MSVCR100D.dll
I am linking using /MTd option which is what the docs I read suggested for static linking.
Can anyone please let me know how to link msvcr100d.dll statically so that even if msvcr100d.dll is not present on the target system, my MSI installation succeeds?
The "D" in MSVCR100D.dll indicates that your native custom action DLL is a debug DLL. The "D" dependency won't be on the target machine unless they have various SDKs installed. Rebuild your DLL in release and the dependency will change to MSVCR100.dll
Also, since you are using WiX / Votive, there is a Visual Studio WiX C++ CA project type that creates the project for you. My experience has been that all of the default compiler and linker settings are good to go out of the box when you use that project type.
I have noticed the same problem. In my case, I am trying to debug my custom actions running in the context of the installer, so I do want to install debug versions.
The Visual Studio debug CRT DLL's are not redistributable, by Microsoft policy. Apparently, it seems furthermore that a 64-bit DLL compiled with Visual Studio 2010 using /MTd (static linking, debug configuration) produces output with a dependency on MSVCR100D.dll. In the 64-bit release configuration, as expected, compiling with /MT results in no dependency on MSVCR100.dll.
One solution is to install Visual Studio on the target test machine. Microsoft offers further suggestions here.
I've just recently started working with Visual Studio this summer, primarily on CUDA and OpenCV related projects. Prior to this, I had been doing my development on Linux for CUDA using Makefiles and the common.mk makefile from NVIDIA.
So my question is as follows: I've not been able to figure out for the life of me what the difference between some of the different project templates are. I know that I've had to use "Empty Project" from the general tab of the Visual C++ options, but that's more trial and error, rather than actually knowing what is going on...
A Win32 project is used if you want to end up with a DLL or a Win32 application usually using the bare WinAPI. A common language runtime (CLR) project is used to create C++/CLI project, i.e. to use C++/CLI to target the .NET platform.
The main difference between projects is what Visual Studio comes up with in terms of pre-created files. A windowed Win32 application for example (what you get when you choose Win32 project, but not a DLL) is created with a file for resources (menus, accelerators, icons etc.) and some default code to create and register a window class and to instantiate this window.
When creating a Win32 project, the linker Subsystem is set to Windows. When creating an empty C or C++ project the subsystem is set to console. Likewise the entry point in the settings for Win32 projects expects a WinMain or DllMain while a console expects an int main. A CLR allows you to mix C++ and .NET which is usually discouraged against.
A Windows subsytem can target executables, dlls, libs or driver/native(sys) files. While a console subsystem targets console binary executables. WinMain is typically used when creating an actual Window application using the CreateWindowEx API, establishing message callbacks and inserting a message handler loop.
A console subsustem with int main can also create a Windowed application only you're better off doing it with WinMain.
A Dll empty project sets the subsystem to Windows and setting to the compiled output to (.dll) as well as the entry point to DllMain/APIENTRY and a static lib will do the same as the Dll except it will set the output to (.lib).
Setting the project to Native subsystem will require the Windows Driver Development Kit to compile drivers.
I have designed an application that requires no install and can be used by non-administrators. I would rather not lose this functionality but when I use the .exe on other computers than the one I programmed it on I get an error that a missing MSVCP100.dll is preventing the file from executing.
What am I doing wrong here? How do I include the file in my release build?
Thanks!
Configure your project to statically link to the C/C++ runtime instead of linking to the runtime DLL:
Configuration Properties | C/C++ | Code Generation | Runtime Library
Select Multi-threaded (/MT) (or Multi-threaded Debug (/MTd) for your debug build).
As an alternative, you should be able to get xcopy deployment of the C/C++ runtime DLL using the technique documented on http://msdn.microsoft.com/en-us/library/ms235291.aspx under the heading "Deploying Visual C++ library DLLs as private assemblies". I haven't tried that technique, as it's generally simpler to just statically link if you need xcopy installation of a native C++ program.
http://msdn.microsoft.com/en-us/library/ms235299.aspx
Distributing apps that have been compiled with Visual C++ requires distributing the C++ runtime .dlls that your app uses. In your case, I assume you want to just distribute a folder, so follow the directions (appropriately modified for your app) here:
http://msdn.microsoft.com/en-us/library/dd293565.aspx
Or just copy msvcp100.dll into your application's directory alongside the .exe and you'll be good to go.
32-bit msvcp100.dll is in C:\Windows\SysWOW64\
64-bit msvcp100.dll is in C:\Windows\System32\
What am I doing wrong here
What you had was dll hell. You had unintentionally used a dynamic linkage with the previous compiler where it just happened on most target systems there was an appropriate C runtime. Windows often included VC 6 CRT, and with more recent SP even VC7 & 8 CRT.
When you changed to the latest VC compiler most systems will not have the new VC runtime pre installed for you.
As Michael Burr says, you can have your 'no install' back if you link statically.
Or you could include the CRT and manifest in the same folder, still doesn't require install.
Or include the vcredist.exe from VS2010 and have a 1 off install
You need to install Microsoft Visual C++ 2010 Redistributable Package.