I know I am not allowed to merge NHibernate to my "commercial" software but what with merging all assemblies required by NHibernate directly to NHibernate.dll?
You might be able to do that, technically, but in most cases, embedding assemblies as resources is more likely to product working results than is using ILMerge.
Even the author of ILMerge admitted that he might have never written ILMerge if he had known how to do assembly embedding.
Much more detail at: https://stackoverflow.com/a/8964905/63225
Related
Simple question for I bet a not so simple answer.
Think of a project like Wordpress. The base of Wordpress is great and the developers built it to be extended with widgets or plugins etc.
Now think NHibernate, specifically with Fluent Mappings.
Put them together and you have a great and stable "base" system BUT how do you load mappings presented from external assemblies? I realize that the system would have to load the Assemblies on the fly using reflection but how do you configure nHibernate, Fluently, at first run to realize that there are extra entities to be loaded from those assemblies? How do you reference them?
I know you can;t add Mappings at run-time after the configurations is made, well you have to recreate the SessionFactory. This is why I want to load all required entities at runtime.
I also know that this can be somewhat accomplished with Dependancy Injection but I do not wish to go that route nor want the extreme baggage that comes with it.
If the plain old nHiberante config file can be modified and then referenced at runtime to reflect new Entities I can only assume there has to be a way to do it Fluently.
Also, based on answers: do you make the configuration from the base project or a DATA ACCESS assembly?
Thanks for your help.
You can pass an NHibernate Configuration object to Fluently.Configure(). That way you can update the configuration. You need to re-create the session factory when you do that, like you said.
You can scan the assemblies in the bin folder for assemblies that contain fluent mapping classes (Assembly.Load, then check
Assembly.GetExportedTypes()
.Any(x => x.IsClass
&& !x.IsAbstract
&& typeof(IMappingProvider).IsAssignabledFrom(type))
or similar) and add the assembly. When all assemblies are scanned, (re-)create the session factory.
I'm doing something similar in an extensible application framework I have written (although I've moved to from Fluent NHibernate to NHibernate mapping by code, but the principles are similar).
I've downloaded the fluent hibernate 1.2 zip file from the website.
It contains various files, amongst them
NHibernate.dll
FluentNHibernate.dll
Castle.Core.dll
Remotion.Data.Linq.dll
Antlr3.Runtime.dll
Iesi.Collections.dll
NHibernate.ByteCode.Castle.dll
Q1) Are all these files required for doing a simple application?. By simple I mean that the db contains a few tables that doesn't need complicated queries and has limited levels/amounts of reference keys and joins.
Q2) Does fluent nHibernate run on mono on linux?
no; see here for what's needed and what's optional.
it runs wherever you can run (and develop) .net programs (i.e it, obviouslly, needs .net runtime environment).
I have 2 .net dll's which I expose to COM using REGASM. In order to simplify referencing within a COM client I would like to make these into one file.
I have tried converting both files to IDL and then copying the contents of the Library section of one into the other and then compiling back to .tlb with MIDL. This works fine for the TypeDefs within the second IDL however it seems to fail when it comes to the interfaces I copied in. OLE/COM viewer can see the interface definitions but when I try and use the TLB via COM it cant find the interfaces that I copied in.
I wanted to make sure before I spend too much time on this, that it is actually possible to meagre IDL's in this way.
Could you use ILMerge to first combine the .NET assemblies and then use REGASM on the resulting assembly?
ILMerge is a utility for merging
multiple .NET assemblies into a single
.NET assembly. It works on executables
and DLLs alike and comes with several
options for controlling the processing
and format of the output.
I don't see an obvious way this would fail. You said you merged the library sections but you didn't say you copy-pasted the interface declarations from the other .idl. That would be an obvious, but unlikely, explanation.
One failure mode is when the client app uses the type library to marshal interface pointers across apartment boundaries or out-of-process. That however requires registry keys in HKCR\Interfaces. .NET doesn't create them, you'd have to do that yourself. You'd know if you did, not much of an explanation either.
Ok so it turns out that the issues I was experiencing were not related to merging the idl's.
If you wish to merge to idl's you can do so by simply copying the content of a library section in one idl into another. Then run midl on the merged file to turn it into a tlb.
I'm trying to work with an existing home grown implementation of click-once. Currently we manually update the manifest for assemblies that we actually changed. I'm attempting to make it automatic based on a binary comparison of the existing assemblies and the newly built assemblies. Unfortunately, it seems that each time I run clean + build (automated build script) there are small differences to the assemblies, essentially invalidating the use of our click-once solution at all. I'm guessing that these differences are caused by some sort of guid generation or something along those lines. Is there anyway to prevent the differences in the assemblies?
And unfortunately, due to our branching/CI strategy I don't have the option of not cleaning because each release is from a new branch.
Otherwise, any suggestions on how I can compare two assemblies to see if any code has changed, without having access to the source code.
Thanks,
David
Typically, autobuild systems check the filesystem timestamps of the binary vs the source files (or object files vs source files, depending on the language). If the source is newer than the binary/object, a rebuild is triggered. This strategy may work better for you instead of actually diffing binaries/
I found BitDiffer a tool from www.BitWidgets.com that compares what has changed in an assembly. While this runs slower than a binary comparison, it removes the need to have MSBuild create an identical assembly.
Thanks,
David
I want to remove AssemblyInfo.cpp, because of some metadata errors that sometimes come up.
Is AssemblyInfo.cpp useful for anything? Or can it be removed without any problem?
I've discovered one distinction for this file: it has to do with values reported under calls to Assembly.GetReferencedAssemblies. I was working on tracking version numbers of our binaries from our SVN repository by embedding the revision numbers into them. Initially I too was updating AssemblyInfo.cpp and found nothing reported in the file property details tab for the binary. It seemed this file did nothing for me in terms of updating those details, which was not the case with similar updates to a csproj's AssemblyInfo.cs. Why the difference right?
Now in one such csproj we happen to reference a vcxproj and that csproj dumps to a log the versions of all its referenced assemblies using the .NET Assembly.GetReferencedAssemblies method. What I discovered was that the number that was being reported in that log was not the vcxproj's version as given by the VS_VERSIONINFO resource I added (which does get the version details into the file properties details tab). Instead the number reported was actually matching that defined in the AssemblyInfo.cpp.
So for vcxproj files it looks like VS_VERSIONINFO is capable of updating the contents you find under the file properties details tab but AssemblyInfo.cpp is capable of exposing the version to GetReferencedAssemblies. In C# these two areas of reporting seem to be unified. Maybe there's a way to direct AssemblyInfo.cpp to propagate into the file details in some fashion, but what I'm going to wind up doing is duplicating the build info to both locations in a prebuild step. Maybe someone can find a better approach.
So far I never had the AssemblyInfo.cpp in my managed c++ dlls, so I don't think it is necessary.
(I just added the file to have version information for my c++ dlls).
Why not just fix the errors? On that note, what errors are you getting?
This file provides information such as a version number which is definitely needed in order to use the assembly you have built.