I have already built a project, and run it in VS2010.
But if I want to run the .exe on other computers which does not
install Visual Studio, it will need .dll files (such as msvcrt.dll and
msvcp60.dll in WINDOWS\SYSTEM32, and some other dlls in the
development package). I didn't use MFC in this project. How to static
link all these dlls into the .exe file in Visual C++ so that I don't
have to copy all the dlls to the other machines?
BTW: I don't want to make install package either
Thanks
Siba
You can set your project to statically link the CRT, by using the /MT flag for the runtime library. Or, you could keep the /MD setting, and install the vcredist package along with your executable (you can get it from here, and also from one of your VS2010 installation folders). To get an idea of each options pros and cons, read this.
Oh, and a similar question has been asked before...
Related
I have a dll project which I need to install into the GAC, on our Production machines.
(I wish I didn't have to use the GAC but SSIS insists)
gacutil.exe is not available on the target machines and using "Enterprise.Services" from PowerShell does not work (I don't know why)
My understanding is I should created a msi installer project.
However after installing the Setup and Deploy Extension to Visual Studio (2015 soon to be 2017), I discovered those projects cannot be built by our Build Server because it uses MSBuild, and MSBuild can't build vdproj project files.
What is the correct way, using a CI build pipeline (MSBuild), to create build artifacts, which can install dlls to the GAC, of a Production Environment?
Note: there are several partial answers on SO, but I could not find any, which were up to date/answer my whole question. Please keep that in mind when answering.
You need to break this down into several user stories. You aren't finding partial answers, you are finding actual answers for specific questions. What you ask is more like an epic.
In general I would create an MSI using Windows Installer XML. WiX/MSI can install files to the GAC without using GACUTIL. If you use the WiX Visual Studio extension "Votive" you can create a .SLN / .WIXPROJ / .WXS that can be built using MSBuild. You can then put this into a source control system such as Git/TFVC/Subversion and use a build system such as VSTS V.Next Build, XAML Build, Concourse, Jenkins to automation the pipeline to build the MSI.
I am developping a multi-platform application under Linux. To build the Windows versions, I make use of cross-compiling with MinGW. For "first" tests, I am using wine. First, I have started with MinGW32 and wine configured for Windows XP.
I need to build tier dll and my own dll. Build is alright. If I copy them in C:\windows\system32\ and run my application which use these dll under wine, it does not find them. If I put a copy of the dll in the same directory than the application, it works.
I have tried :
~/.wine/drive_c/windows/system32/
/root/.wine/drive_c/windows/system32/
If I run the explorer (wine explorer), and browse into C:\windows\system32\ , my dll are not there !
Thus, how can I make wine find home made dlls ? I have had a look at winecfg and winetricks, but they are of no help.
Cheers,
Laurent.
Try creating an installer for your application, using nsis or something, and creating a package that includes your dll and application. Then install that installer using wine.
I know that visual studio has A LOT of required files to launch anything through an executable, is there a way I could create an .exe that doesn't require all the excess files like you would with a JAR file? I know they are completely different but I'm just trying to find out what we can do other than installing the application on the users PC. Thanks!
is there a way I could create an .exe that doesn't require all the excess files like you would with a JAR file?
Partly. If you're using VB.Net, you will always need to verify that the machine where you run your executable has the .NET Framework version which you target.
Most systems already have some .NET versions installed, which will allow your .exe to "just work" (provided you don't use any libraries apart from the framework). Targeting an older .NET framework (like 3.5) will allow your exe to work on any system with .NET 3.5, without any other files.
I am trying to make a program that works on every operating system by forcing it to load and use the DLL's in the current directory, not the windows directory, but it don't works. I tried to enable "copy local" and change the refference path, but without any success, the program tries to load the DLL's from the windows directory.
My question is: how can I fix this?
The Search Order for DLL's is documented here on MSDN. It also includes instructions on how you can modify the search order so that the local bin directory is searched first, instead of the GAC.
The directory %windir%\assembly is called the GAC. Assemblies are not copied there, but installed typically using gacutil /i or by installation packages.
GAC is a suitable folder for libraries referenced by lots of other libraries and applications in build versions that are not centrally coordinated. Using GAC allows you to have multiple versions of the same library, all of which might be indirectly required even by a single application, installed side by side on the system. Case in point is the .NET framework itself.
The assemblies that you build are probably not that kind. Application assemblies and libraries that are basically part of a single application should never make it to the GAC or you can get into trouble. There is a variety of possible trouble:
one accidentally or intentionally creates different (incompatible) builds of the same library with the same version number.
assembly in GAC references an assembly not in GAC
one app installs the same assembly into GAC, but another app wants to load it from its local folder (where application binaries reside).
Code in the GAC gets a preference when assemblies are loaded. To remove an assembly from the GAC, use gacutil /u.
In BDS 4.0 I've build a VC-Style DLL, I want that this DLL includes all packages in order to be independant as well, I can use it and deploy it even on PC that haven't the Borland RTL installed.
(I've BDS in a Virtual Machine and VC++ on my host computer).
So, I modified compiling options like this:
Uncheck the use of dynamic RTL
Check "Build with execution packages:" and list all packages that I want to include (rtl, vcl, ...).
But when using this DLL in VC++, LoadLibrary fails and ask to me to add rtl100.bpl, vcl100.bpl, ... in the package.
If I copy all BPL that are on my virtual machine to my host computer, LoadLibrary works.
How can I include all these packages in my C++Builder DLL?
You have uncorrectly checked "Build with execution packages" option. When it's checked, all listed packages are linked dynamically so you'll need to distribute *.bpl files with your application. If you uncheck this option, all packages will be statically linked into your dll