I'm modifying a DLL through dnSpy, and said modification required a reference assembly in order to recompile. The modification did not necessitate the reference assembly, it was just needed in order to recompile the changed section, with or without the change.
So, my question is this: Does the reference assembly chosen modify the recompiled DLL? For example, if I had two different versions of the reference assembly, one which the DLL was originally compiled with and meant to use, and the other a different version I used during recompilation using dnSpy, which reference assembly would the recompiled DLL use?
Related
I have an executable that looks for a particular DLL. I have changed the source for DLL and recompiled it (written and recompiled in VB6). Once I replace the DLL, the executable hits a runtime error when it gets to using that particular DLL. Works ok when I recompile the executable.
So my question is, with same DLL path, same name, and virtually identical DLLs, why does the executable need to be recompiled?
This is driving me bananas so any thoughts would be appreciated. Thanks, Callum.
A VB6 (or any COM) DLL has unique IDs for itself and its public interfaces, if you recompile these can change and any existing code bound to the old IDs fails.
Tldr; Tick "Binary Compatibility" in the DLL's project options & select the old working DLL as the thing to maintain compatibility with & recompile.
Detailed explanation: I keep hearing about DLL hell - what is this?
I have a project with a custom control overriding a default control from the system.windows.forms namespace. This works fine, but I discovered I needed to modify a DLL this project depends on with some code that needs to know about the existence of this custom class; this code uses the class name of the control to do various things.
As the project depends on the DLL, and circular dependencies are not-a-good-idea, I moved the custom class to a third DLL which is a new project by cut-and-paste, and set the project and library to depend on this new lib, and set this new library to be built first, before the two other projects, and added an assembly reference.
So far so good; I can now import this new namespace and use it in my code. But, now the existing uses of the custom control are broken in any 'designer' based code, as they still point to the default namespace. I've tried adding a reference under Project Properties > Imported namespaces, yet this is insufficient: the code likely needs to contain the explicit line imports <myNamespace>. And while this is no-problem for regular files, when you have a designer file it's important to not manually modify it.
What's the easiest proper way of informing visual studio that any custom control named say X should now be accessed as myNamespace.X?
The procedure as done in the question is correct, with one caveat: Check the .NET version, and if different set the target version to the lowest common denominator. If you use a newer Visual Studio than the original that was used to make the solution, it's likely there's a newer .NET out as well. By default, the latest .NET will be used for new projects. Visual studio will also happily attempt to build the projects with disparate .NET versions, and complain that it can't find references, then surreptitiously hide the version mismatch as a "Warning", even though linking assemblies with different targets is by default impossible.
The designer will then happily accept the custom class even if it's defined in another project.
I have a vb.net application I'm looking to be able to distribute in the near future.
I'm not the original architect and the previous developer referenced a handful of .dll's that are under a GPL license.
All of the software that includes these dll's are freely available online, so my customer can go download and install them if they need that functionality. So I don't have to distribute the DLLs.
Currently they are referenced under the "Reference" part of the project file.
My question is, how do I resolve these dll's in a way similar to how the "references" dons it, but at runtime.
My plan is to search the registry for the location of these dll's and reference that location, but given the file location of the .dll, how do I "pull" that code into my project.
Thanks
You may try this
Search for Dll on specified path for dll
Use reflection to load assembly or dll into you code at runtime
Create runtime object from the loaded dll
Call required functionality from the dll
Reflection is the key solution to your problem that you may use to plugin new functionality into your project without distributing the dlls
This is the only solution that works
http://mylifeandsql.com/2018/03/26/replication-readpast-error/
also you can just start your migration with the following command
Sql(#"SET TRANSACTION ISOLATION LEVEL READ COMMITTED");
This will replicate dll changes like adding new column to a replicated table
You will also find that the column is automatically added to replicated articles > columns
No need to create a new snapshot nor set the sync to re-initialization ☺
Thanks
Getting error
A reference to "file path\file.sln"could not be added. please make
sure that the file is accessible and that its is a valid assembly or
COM component
You mean adding a reference inside a project?
If is this, you can´t add a reference to a whole .sln, you will need to choose, for example, a valid .dll of the service you are trying to reference.
A reference to "file path\file.sln" could not be added.
That's a solution file.
[...] and that its is a valid assembly or COM component
A solution file is not an assembly or a COM component, hence the error. You need to add a reference to an actual assembly. If it's a project in your current solution, add a Project Reference. If it's not in your solution (and for whatever reason can't be added, though I highly recommend adding it if at all possible) then you'll need to add a reference to the compiled .dll of the referenced project.
You can't add references to solution files, project files, anything like that. Those are just XML metadata about projects. You need the compiled output, the assembly.
I get the following exception when showing a form:
InvalidOperationException was unhandled
Mixed mode assembly is build against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.
alt text http://img69.imageshack.us/img69/2599/captureya.png
Dont really know why this isnt working. Any help?
I haven't seen the code for LoginForm. But I think you need to set an app.config flag to fall back to .NET 2.0 era bindings...
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
First, what's a mixed mode assembly? A
mixed mode assembly is an assembly
that contains both managed (CIL) and
unmanaged (machine language) code.
Consequently, they are not portable to
other CPU instruction sets, just like
normal C and C++ programs and
libraries.
Next, why use them? The primary
purpose for mixed mode assemblies is
as "glue", to e.g. use a C++ library
class as a base class of a managed
class. This allows the managed class
to extend unmanaged methods, allowing
the managed code to be polymorphic
with respect to existing unmanaged
functions. This is extremely useful in
many contexts. However, as something
like this involves extending a C++
class, it requires that the compiler
know all about the C++ compiler ABI
(name mangling, virtual function table
generation and placement, exception
behavior), and thus effectively
requires native code. If the base
class is within a separate .dll, this
will also require that the mixed mode
assembly list the native .dll as a
dependency, so that the native library
is also loaded when the assembly is
loaded.
The other thing that mixed mode
assemblies support is the ability to
export new C functions so that other
programs can LoadLibrary() the
assembly and GetProcAddress the
exported C function.
Both of these capabilities require
that the shared library loader for the
platform support Portable Executable
(PE) files, as assemblies are PE
files. If the shared library loader
supports PE files, then the loader can
ensure that when the assembly is
loaded, all listed dependent libraries
are also loaded (case 1), or that
native apps will be able to load the
assembly as if it were a native DLL
and resolve DLL entry points against
it.
Source
I had this issue, tried the answer above and it did not work.
After much reading and trial and error and not finding anything that worked I noticed that I had both imported the Mysql dlls and added them in properties. After I removed the import statements it worked.
I know it was removing the import statements because I tested between every change I tried.
Hope that helps somebody.