We have recently decided to start shipping the versions of some of the DLL files that a product requires with the product itself.
This is to guard against the situation where (for example) the MVC DLL file is updated on the server to which the software is deployed and the product fails to work as it was written against the now previous version of the DLL.
If the MVC DLL file of the specific version is included in the product and "locally" referenced this prevents this problem from happening. (In an ideal world every product which will be installed onto the destination server would be updated to the most recent version but this is not always practical)
My concern and question is whether this is going to give a false sense of security or not actually cope with the problem in the following situation: if Version 1.0 of the MVC DLL file is relying on method X of standard Microsoft DLL library Y and this DLL file Y is updated we will be in the same situation of having a broken product?
Assuming you meant the MSVC (Microsoft Visual C++) DLLs, the correct solution is to use an application manifest. The MSVC DLLs support Side by Side installation (SxS). This means that a new version of those DLLs does not replace an old version. Your application manifest tells Windows which DLL version(s) you want.
I don't know about MVC specifically, but you have a bigger problem if the conflicting version of a dependency dll is installed to the GAC on your target machine, as it will be used in preference to the local file.
Depending on how big it would make your final product, consider statically linking your program. This will prevent the much dreaded DLL hell since you wont have to give DLLs out.
Related
I have an issue with these two famous warnings which are raised during compilation of our solution. There are many forums about these already and I read those, but they still don't solve my issue completely...
1. There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "XXX", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
2. Referenced assembly 'XXX' targets a different processor than the application.
The reason why these appear in our case is clear. Our solution is compiled as AnyCPU and we want to keep it this way, as we do not want to compile it twice (once as x86 and second as x64). However, we use external DLL which is either x86 or x64 (it is not delivered as AnyCPU).
We develop the application on 64bit windows, so we use the x64 DLL version as reference in the visual studio during development. When we deliver the application to end-users, the installer is customized to copy the proper DLL based on the platform of the target system, e.g. when it is installed on 64bit windows, it copies the x64 DLL version and when it is installed on 32bit windows, it copies the x86 DLL version. Therefore, we know that everything is finally ok, and we can ignore those messages. And therefore, I just want to make them disappear:-)
The first warning can be supressed by the following tag in the project file:
<PropertyGroup>
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
But I did not find anywhere how to get rid of the other message? Is this possible as well?
I know that this is just small issue and I can live with that. However, there is something like "Warning Free Build Initiative" going on in my company, so I'd like to get rid of all warnings we have.
Thank you in advance for any hints,
Tomas
Our project uses several NuGet packages, a few of which reference LinqBridge, a library that re-implements LINQ to Objects for C# 2.0. The LinqBridge.dll file lives under /packages/PackageName/lib/20/LinqBridge.dll, so it clearly is supposed to only apply to .NET 2.0.
The problem is that, even though every project in the solution is configured to build to .NET 4.0, the LinqBridge.dll binary gets copied over to the final /bin directory and wreaks havoc in Razor views. If I perform .Select() on an IEnumerable, there is an ambiguous call between the built-in LINQ call and the re-implemented one that LinqBridge provides.
I clearly do not need the re-implemented version; if I simply delete LinqBridge.dll from the output /bin directory, everything works just fine. However, that is not an acceptable permanent solution.
Is there any way I can configure something to quit copying that file, which is for an old .NET version, into the /bin output?
Edit: I duct-taped together a solution by adding this to the "Post-build event command line:" commands under "Build Events" in my solution properties:
del $(SolutionDir)\bin\LinqBridge.dll
It's still far from ideal, but at least it lets my project run for now.
NuGet has support for different binaries for different .NET versions so I would suggest that the packages you are using are built badly.
I would contact the authors of the packages and see if they can fix them so that only the net11 or net20 versions include LinqBridge.
Supporting Multiple .NET Framework Versions and Profiles
Many libraries target a specific version of the .NET Framework. For example, you might have one version of your library that's specific to Silverlight, and another version of the same library that takes advantage of .NET Framework 4 features. You do not need to create separate packages for each of these versions. NuGet supports putting multiple versions of the same library in a single package keeping them in separate folders within the package.
(more...)
A useful approach we found was using the LinqBridge.Embedded Nuget package instead of the standard LinqBridge package. This embeds Linqbridge as a C# file within your project, and hence does not get copied over to the bin folder and loaded into the context of the Razor view.
This was useful to us because an assembly we reference still needs to be built in .Net 2.0, as it is also referenced by a 2.0 application. Hence that assembly uses LinqBridge.Embedded, and the LinqBridge assembly does not end up in our 4.0 servers' bin folders.
I am building a win32 executable. The compiler is the latest version of MinGW. The library dependencies are GLUT and libpng.
I first tested on a windows 7 machine, and had to obtain libpng3.dll and freeglut32.dll. However, on XP, I had to (in addition) acquire zlib1.dll.
The XP machine was a VM with a fresh install, so I suspect a fresh win7 machine may also be lacking zlib1.
My question is how do I go about finding out which dll's I need to distribute? How do I know, a priori, which dynamic libraries are needed for my program to run on a particular system? I suppose this is what installer programs are for... I'm guessing that what the installer does is look through the system to find out which dependencies are unsatisfied, and then provides them. So this way if I were to distribute my program I could check if the user's machine already has zlib1.dll, and I won't install zlib1.dll if it's already found in the system directory. However I never found a document that said to me specifically, "libpng requires zlib", and so, until such point as I tested the executable on a machine lacking zlib, I was unaware of this dependency. How can I create my dependency list without having a fresh install of each version of every operating system to test on?
One idea I have is to decompile the executable, or through some method examine the linking process, to find all the libraries that are being linked at runtime. The problem now becomes figuring out which of these are supposed to already be there, and which of them I could be expected to provide in the distribution.
edit: Okay, I looked, and the installation of libpng I downloaded did provide zlib1.dll inside its bin directory. So not including it is pretty much my fault. In any case, Daniel's answer is definitive.
Dependendy Walker shows all deps of your program.
The correct answer to this question, in my view, is to start at the source rather than to reverse engineer the solution with Dependency Walker, awesome and useful tool though it undoubtedly is.
The problem with Dependency Walker is that it only tells you what one particular run of the program requires on the OS on which you run it. If you have any dynamic loading dependencies in your app then you would only pick those up if you made sure you profiled the app with Dep. Walker and forced it through those dynamic loads.
My preferred approach to this problem is to start with your own source code and analyse and understand what it depends upon. It's often easy enough to do so because you know it well.
You need to understand what are the deployment requirements for your compiler. You usually have options of linking statically and dynamically to the C++ runtime. Obviously a dynamic link results in a deployment requirement.
You will also likely link to 3rd party code. One example would be Windows components. These typically don't need deployment, you can take them as already being in place. Sometimes that's not true, e.g. GDI+ on Windows 2000.
Sometimes you will link statically to 3rd party code (again easy), but if you link dynamically then that implies a deployment requirement.
I've written a Open Source program that I've released as GPL built using the Qt4 LGPL SDK. This program has the ability to search an optional Sqlite3 database for data.
Here is what is making me lose my mind. I compile the program on the development machine. When I try to run it, I can errors about missing DLLs. I copy those dlls into the same directory as the executable and it now works fine ( mingwm10.dll, libgcc_s_dw2-1.dll, QtCore4.dll, QtSql4.dll, QtGui4.dll ), including the database search.
Now, if I copy that folder with the executable and the DLLs to a new machine that has not had the SDK installed on it, it runs fine until I try to search. As soon as I hit the search button, I can the following error:
Title: Microsoft Visual C++ Runtime Library
Runtime Error!
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I then download and install the SDK, doing nothing else, I can now run the program and search the sqlite3 file just fine!
What magic am I missing?
P.S. Both machines are freshly installed Windows XP systems.
You may have some libs or Qt plugins that are not deployed to the target machine. It most likely is the SQL driver plugin. Here's some info about it: http://doc.trolltech.com/latest/deployment-windows.html#qt-plugins
You'll need to copy the needed Qt plugins to a directory next to your executable. And add something like this in your main():
QApplication::addLibraryPath(QCoreApplication::applicationDirPath() + "/plugins");
(Edited link and added code)
I found the problem.
Stephen Chu was correct in that I was missing the sqlite driver. However, I can into more complications along the way.
The SDK comes with two sets of dlls. One set resides in $BASEDIR/bin and the other in $BASEDIR/qt/bin. The former contains the dlls used by Qt Creator, while the latter are the dlls that you want to ship with your executable.
I needed to take the sqlite plugin ( qsqlite4.dll ) and copy it to APP_DIR/sqlplugins. My problem was I was using the wrong qsqlite4.dll file.
A big thanks to everyone who contributed to this question.
For future reference, this issue was also discussed here: http://www.qtforum.org/article/34639/qt4-program-crashing-unless-sdk-installed.html
I have a project written in C++/CLI. Some of the types there are in managed code, and some are in completely native code. Let's say I have the produced DLL on a machine that dosen't have any version of the .Net framework installed, is there a way that another, native application will link with my "mixed-mode" Dll and use only the native types? I've noticed that the minute I add the "/clr" switch, my Dll automatically depends on several .Net Framework Dlls (mscorjit, mscoree etc.), and when I actually try to use the 100% native types defined in it, the application still tries to load those .Net Framework Dlls (even though I don't use the framework in that part of the code).
So, is it possible to avoid loading those Dlls in such case? (as I see it, the other option is to create another, native project, that will contain all of the native types, without the managed ones).
Thanks
No. When you load a mixed mode assembly (/clr), right after DllMain runs, the .cctor runs and initializes the framework, if it hasn't already been setup for the application.
Without this, there would be a big hit as soon as you called a function that required a managed API. For details, see "Initialization of Mixed Assemblies" on MSDN.
The best option would be to make your native API a separate DLL, and have the mixed mode assembly a separate project, so you can load it separately if required.