Build a Visual Studio Project without access to referenced dlls
I have a project which has a set of binary dependencies (assembly dlls for which I do no have the source code). At runtime those dependencies are required pre-installed on the machine and at compile time they are required in the source tree, e,g in a lib folder. As I'm also making source code available for this program I would like to enable a simple download and build experience for it. Unfortunately I cannot redistribute the dlls, and that complicates things, since VS wont link the project without access to the referenced dlls.
Is there anyway to enable this project to be built and linked in absence of the real referenced dlls?
Maybe theres a way to tell VS to link against an auto generated stub of the dll, so that it can rebuild without the original? Maybe there's a third party tool that will do this? Any clues or best practices at all in this area?
I realize the person must have access to the dlls to run the code, so it makes sense that he could add them to the build process, but I'm just trying to save them the pain of collecting all the dlls and placing them in the lib folder manually.
Maybe one of these ideas will help you to solve the problem:
To all the good advice above, agreed. That being said, maybe there is a valid scenario where the external DLL's are generally not needed? So here is what you do. You wrap and isolate them. (Its a higher level of abstraction than creating interfaces, so a bit easier to maintain).
In Visual Studio, if you do not recompile the specific VS Projects which reference the external DLL's then you can get away with compiling the rest of the VS Solution's Projects without having those DLL's handy. Thus if you somehow wrap the external DLL's with your own DLL's and then distribute those wrappers as binary only, the person sharing your source code will not need the external DLL's to compile the main solution.
Considerations : 1. Extra work to separate out the wrapper code into isolated Projects. 2. The other VS Projects must add references to your wrapper DLL's as "File System" references to a "LIB" folder, rather than "Project References". 3. The VS Solution configurations must disable compile for the wrapper DLL's. A new configuration should be added to explictly re-compile them, if needed. 4. The VS Project definition for each of the Wrapper DLL's should include a post-build event to copy them to the expected "LIB" folder location. 5. At runtime, the external DLL's must be present in the application's bin directory, or the machine's GAC, or otherwise explictly loaded. NOTE: If they are missing, it is only when they actually invoked at runtime that their absence will result in a runtime error. ie You do not need to have them if the code doesn't happen to call them in a general situation. 6. At runtime, you can catch errors loading the external DLL's and present a pretty error message to the user to say "In order to user this function, please install the following product: xyz". Which is better than displaying "AssemblyLoadException... please use FusionLogViewer... etc" 7. At application startup, you can test and detect missing DLL's and then disable specific functions which depend upon them.
For example: According to this pattern I could have an application which integrates with Microsoft CRM and SAP, but only for a specific function, ie Import/Export.
At design time, if the developer never neeeds to change the wrapper, they will be able to recompile without these external DLL's. At runtime, if the user never invokes this function, the application will never invoke the wrapper and thus the external DLL's are not needed.
Well save them the pain of collecting all the assemblies and place them in the lib folder yourself. Then commit them along with the source code in the repository. This way people checking out the code from the repository will also get everything that is needed to compile the project.
链接地址: http://www.djcxy.com/p/45206.html