I've got a certain project that I build and distribute to users. I have two build configurations, Debug and Release. Debug, obviously, is for my use in debugging, but there's an additional wrinkle: the Debug configuration uses a special debugging memory manager, with a dependency on an external DLL.
There's been a few times when I've accidentally built and distributed an installer package with the Debug configuration, and it's then failed to run once installed because the users don't have the special DLL. I'd like to be able to keep that from happening in the future.
I know I can get the dependencies in a program by running Dependency Walker, but I'm looking for a way to do it programatically. Specifically, I have a way to run scripts while creating the installer, and I want something I can put in the installer script to check the program and see if it has a dependency on this DLL, and if so, cause the installer-creation process to fail with an error. I know how to create a simple CLI program that would take two filenames as parameters, and could run a DependsOn function and create output based on the result of it, but I don't know what to put in the DependsOn function. Does anyone know how I'd go about writing it?
You can read the PE imports table to find out what DLLs are required at load time. This is what Dependency Walker does, and also the dumpbin tool included with the Microsoft Platform SDK (which is installed by Visual Studio and also available as a separate download). Some of the debughelp APIs provide access to information from the PE header, but why not invoke the dumpbin tool and inspect its output? Since it's text-based non-interactive it should be pretty straightforward to integrate into your installer build process. Dependency Walker also has a capability to run in non-interactive mode with text output.
If you do need to retrieve the information without the help of any other tool, the ImageDirectoryEntryToDataEx function is a good place to start. Also, here's a question that shows how to do it manually (but do use ImageHlp instead, which knows about all the various variants of the PE format):
Printing out the names of implicitly linked dll's from .idata section in a portable executable
Related
I am new into software developing. I have found this GitHub repository which I plan to modify. Let's just say I fork this repository and modify it. How would I then be able to export it from there. By export it I meant turn all of those files into one windows executable file. Thanks.
In general, building a project is a project-specific task unless the project is written in a language (such as Rust) that has a built-in build tool. If you're unclear about the steps to build a project, you should look in the documentation or the wiki for steps about how to do so, and failing that open an issue asking them to document the procedure for building the project.
Just looking at the project, it does not seem obvious that it should produce a binary executable of any sort since it's written mostly in JavaScript.
Usually you use a compiler to turn source code into machine code (exe files).
As bk2204 mentioned, this project is based on Javascript and Node.js.
Javascript is interpreted instead of compiled, so another program (Node.js) reads the source code and executes it directly every time instead of first compiling it into an exe file. That other program itself may be in an exe file.
The project you have linked is a fork of this project, and that one seems to have a Windows launcher/installer exe file (that probably installs or contains Node.js, but I haven't checked).
That installer is available here in both exe and source code form. So you could modify the launcher and rebuild it, but the main app is not in the launcher, instead it's in all the JS files. You may be able to edit the JS files and just use the same launcher without modifying it. There may be a packaging step required after editing the JS files, to package them into a form that the launcher expects. You would need to run this build step after every time you modify the JS files, to provide the new code to the launcher.
You would have to explore the project's structure and build process to find out the exact steps.
If you're very new that may be exceedingly difficult.
You may want to practice by learning Javascript and Node.js.
You could after that try Java which is compiled, and possibly more powerful than Javascript. Just for fun.
Maybe you could do 30 of these practice projects, then you'll have a chance of being able to modify this project successfully.
Currently, I have an MFC C++ visual studio project that is built to a DLL. Let's call it the FinalDLL.
I need this FinalDLL to be configurable. So, I want a GUI such that the users can generate the FinalDLL based on the information the enter via GUI. Please consider that I don't want to make the sources available at any points.
I do not have a clear idea how to integrate these steps. The solution I came up with was to have something like a button in my GUI, so that when it is clicked, the FinalDLL gets generated based on the information entered via GUI. Is it possible to do something like that? Probably I need another DLL library, as the information entered via GUI can be calls to functions that are used inside the FinalDLL source.
The solution to this would be very complex and complicated, mainly due to the fact that you don't want to disclose the source code of the DLL.
Basically you need to compile those source files every time you want to generate the DLL, and without the user having access to them.
Firstly, this is also required for the users that you want your DLL-generator app distributed to.
Secondly, you'll need to store those files somewhere in the app, and in an encrypted form, so that hackers won't just look at you app binaries and extract the source code for the DLL.
As a prerequisite on the user side, he will need to have a compatible Visual Studio installation, which will be used to compile on the fly the source code files.
What the DLL-generator application will need to do is to compile on the fly those source code files along with the customised ones via the form that the application will present.
So what you will need to do (the list might not be exhaustive due to the complex requirements):
Gather all compiler/linker commands that Visual Studio executes when building your project
Store all source code files into your application, in an encrypted form. Now if you want to allow your application to decode the files then you need to either store the encryption key within the application, and obfuscate it so its not that easy to find, or have the app communicate with your server and ask for the encryption key via https (this is a more secure approach, however neither this is 100% bullet-proof, insistent/trained hackers can still peek into the memory used by your app)
After the user fills all DLL generating details, the app will need to decrypt the source code files, updated the ones affected by the customised parameters, and start the build process by using the commands gathered at step #1. The compiler/linker should allow reading from stdin, so you'll use pipes to write the source code contents to the compiler/linker stdin, and to obtain the compiled/linked objects from stdout.
As I said, the solution is not pretty, and the main problem will be having the users install a Visual Studio that comes with a compiler compatible with the one from your machine, otherwise the commands you gathered at step #1 will not work.
Is it hard to compile software so that it is a single .exe file? I have been publishing the program in the traditional manner and the resultant program consists of a setup file and a couple data files. Ideally I would like to have a lone exe that runs program without having to install.
In general, if you're using Visual Basic, you'll always need to, at a minimum, guarantee the target computer has the proper .NET Framework installed.
If that's the case, then you can just deploy your .exe from your Console or WIndows Application project, and it will work, provided you don't use any references or types outside of the standard framework types. If you have any assemblies you use, or require any extra data to exist, then an installer is the correct way to go.
In general, building an installer makes sure that all of the dependencies are in place, which is why it's the "traditional" manner of publishing. Without that, you (or somebody) has to verify the dependencies before running your program manually.
I have a VS2010 C# project, that references a large set of native .dll's (a commercial java runtime). These file are referenced as 'Content' files in the project, since the need to be copied with the project.
The code in these libraries is called using PInvoke, there is no assembly reference.
Every time I compile the solution, the Visual Studio testing framework tries to load all the referenced dll files, expecting to find .net assemblies which may contain unit tests. Since the are no .net assemblies, the following exception is thrown:
Error loading some.dll: Unable to load the test container 'e:\some.dll' or one of its dependencies. If you build your test project assembly as a 64 bit assembly, it cannot be loaded. When you build your test project assembly, select "Any CPU" for the platform. To run your tests in 64 bit mode on a 64 bit processor, you must change your test settings in the Hosts tab to run your tests in a 32 bit process. Error details: Could not load file or assembly 'file:///e:\some.dll' or one of its dependencies. The module was expected to contain an assembly manifest.
This takes a whole lot of time, and I would like to tell Visual Studio to not try to load these files.
How can I tell Visual Studio to stop trying to load these files?
Correct me if I got this wrong:
You are including the P/Invoke target binaries in to the VS solution because you want the binaries to be copied over to the target directory when the solution is built. You want this because the project will execute from the target directory as soon as the VS solution is built. Correct?
Often times VS packages (both default and 3rd party) try to get smart about the solution content and will follow certain triggers (which are difficult to contain and control by ourselves) and load the solution and project content in their own ways. Fighting the battle in this area has poor ROI than employing a simpler work around (below).
While I can't provide you with an authoritative answer on how to tell VS's test package to not load all binaries, I suggest removing such binaries from the project as 'content' and leave them in your source control where they are today. Add a post-build task that will copy the said binaries over to the target. This will still give you the same result as it is working today but, takes those binaries out of reach for the test probes.
You must check out configuration settings by just right clicking on your solution name and click on "Configuration Manager"
It will open a pop up window for Configuration Manager.
Check not for the platform your projects are using it is better to choose any CPU.
Hope this can help.Give it a try:)
Because thats what your exeception says as you have quoted
Thanks
I tried to repro this issue and found that the root cause is that you have set your test project to be compiled as !AnyCpu. Is there any particular reason why you would want this for managed test code?
So unless you change this you will continue to see this message.
If you want to continue using this configuration for your test project you would need to update your .testsettings file as suggested in the message.
Sorry if this seems remedial. I am including it for the sake of completeness.
General library behavior
A library can be referenced either in the project file (and so the compiler injects to code to load the references) or dynamically at runtime with LoadLibrary() or PInvoke calls. When a referenced library is loaded, a function at the entry point is run can in turn load any libraries it depends on. When loading the library, there is a well-known set of paths that Windows will search, including %WINDIR%\Assembly and the current directory. There's a lot of good conceptual information on Wikipedia about this. I recommend reading it.
Possible Root Causes
I can't tell from your question if you are having trouble building the application, building the tests, or executing either. Generally I would not expect PInvoke to cause compile errors.
Error during app build: VS generally will show you that you have a reference to a DLL it can't find. However, you may be missing a DLL that is needed to satisfy all the dependencies. To resolve, just add the reference to the missing DLL. (This is the simplest issue, so I'm guessing this isn't what you're seeing.)
Error during test build: Since your test will reference your application/library, it also needs to have the same reference. Usually the easiest way to ensure you are getting everything is to remove all references and add a reference to the project you are testing. It's possible you some additional libraries are necessary for some tests, but not your app/lib itself. These need to be added separately.
Error during app execution: This can happen when starting the application, or later when an call to the external library is made if late binding is used.
Error during test execution: This can happen the same as with app execution. However, tests can also be "partially built" to only execute a small number of tests. In these cases, some files may not be copied. Using the [DeploymentItem()] attribute, you can specify that a test requires the presence of certain files in the test or app/lib project to function. MSDN describes how this can be done.
Resolution
For #1 & #2 the solution lies in adjusting the references in the project.
For #3 & #4, it may get trickier. There is a similar question to yours regarding Windows Mobile here which you may find useful, especially referring to using dumpbin to list out library dependencies. You can also use procmon from SysInternals to monitor file access during compile or load to see which files are not found. Then you can either include the missing file, or remove the library referencing it.
Good luck. Hope this helps.
I've written a command-line OpenCL compiler. I'd like to have VS compile my kernel source files using this whenever I build the C# project that includes them. I've looked around and found information and custom build tasks, custom tools, etc, but I haven't been able to get it to work correctly.
How can I tell VS to run my exe on the source files in the same way that it runs the c# compiler, etc for other files in the project?
I report errors from this tool by calling Console.Error.WriteLine(). This dutifully places the errors in the Output pane, where I can double-click them, taking me to the appropriate place in the .cl kernel source file. However, the errors don't appear in the VS error panel. ??
Alternatively, if anyone's aware of an existing OpenCL compiler - it's annoying to have to run the host application just to compile the kernel - I'd appreciate a link.
I've managed to get this working by adding a post-build step to the project options. However, I'd really prefer for this exe to be run for every *.cl file in the project.
Update I had neglected to include an error code when formatting my error messages. Correcting them to match any of the formats listed here took care of that issue. Still trying to figure out how to associate an exe with a given file extension, though.