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).
Related
For a long time, I have been very successful at non-invasively customizing many .NET Framework builds by setting CustomBeforeMicrosoftCommonTargets and CustomAfterMicrosoftCommonTargets as environment variables in a command-line shell that corresponds to a given development/build workspace.
I would set these environment variables to point to custom msbuild targets files that would then be automatically imported (before and after respectively) the import of the standard Microsoft provided targets files. This has worked great for a long time, but now .NET Core comes along and I find no mechanism quite like that.
I am aware of Directory.Build.props and that does not appear to be equivalent. For one, it is invasive requiring me to add a file to a source tree that I don't want to necessarily touch in order to customize its build (maybe its an open source project and I don't want to be injecting new files into it). For two, it doesn't provide the dual Before/After import hooks which are very important (if this duality weren't important Microsoft would never have provided it).
I also don't like dropping magic files in magic global locations as my build policies/customizations are themselves versioned source code which can vary from one developer workspace to another (even on the very same machine for the very same developer).
It seems odd that Microsoft would fail to retain such a long-standing and fundamentally useful msbuild customization capability in .NET Core. Am I missing an equivalently powerful, easy to use and non-invasive mechanism? Is it there and I just haven't found it?
CustomBeforeMicrosoftCommonTargets and CustomAfterMicrosoftCommonTargets are still part of MSBuild 15 which is included in VS 2017 and the .NET Core SDK.
Setting them as global variables will still import them and override the default locations used if not set. Use the /bl argument to generate a binary build log and the MSBuild structured log viewer to diagnose issues you may have with it.
I have .NET Core solution with ~30 projects, and I don't get one thing - each project compiled Bin output is very huge. Basically it contains whole bunch of Microsoft.AspNetcore.* and System.* assemblies, which makes output about 15-30mb (even for really small projects).
The solution divided into smaller projects with purpose to make it less coupled, but now it makes more troubles than it helps - overall size of all compiled projects is around 700mb..
I agree that it would be OK for "startup"/"composite root" projects, where everything should be in one place, but now it looks like every project is "published", or like compiled as "standalone" and not using installed frameworks.
It's not a problem as such, but it makes the solution not so robust in terms of CI/CD, publishing artifacts, etc. Any ideas what might be wrong? Is it really as designed?
One possible reason is that for some historical reason my solution targets net461 (aka "full" .NET Framework). However I'm considering porting everything to netcoreapp1.x/netstandard. I tried to do it with some projects - and it looked like for "library" projects it copies only few assemblies, but for some other projects (e.g. tests written with xUnit) - there are still a lot of "framework-based" DLLs, that could be used from global cache or smth.. Even in net461 current situation is still a bit weird.
I also was trying to put all built artifacts into one folder on CI server, but there are other issues with it - like third-party libraries conflicts, when different version libraries in different projects are used. It's understandable for third-party libraries, but "framework" libraries could be "smarter"..
Just for reference, full list of assemblies being copied to Bin output:
Autofac.dll
Autofac.Extensions.DependencyInjection.dll
AutoMapper.dll
FluentAssertions.Core.dll
FluentAssertions.dll
JetBrains.Annotations.dll
Microsoft.AspNetCore.Antiforgery.dll
Microsoft.AspNetCore.Authorization.dll
Microsoft.AspNetCore.Cors.dll
Microsoft.AspNetCore.Cryptography.Internal.dll
Microsoft.AspNetCore.DataProtection.Abstractions.dll
Microsoft.AspNetCore.DataProtection.dll
Microsoft.AspNetCore.Diagnostics.Abstractions.dll
Microsoft.AspNetCore.Diagnostics.dll
Microsoft.AspNetCore.Hosting.Abstractions.dll
Microsoft.AspNetCore.Hosting.dll
Microsoft.AspNetCore.Hosting.Server.Abstractions.dll
Microsoft.AspNetCore.Html.Abstractions.dll
Microsoft.AspNetCore.Http.Abstractions.dll
Microsoft.AspNetCore.Http.dll
Microsoft.AspNetCore.Http.Extensions.dll
Microsoft.AspNetCore.Http.Features.dll
Microsoft.AspNetCore.HttpOverrides.dll
Microsoft.AspNetCore.JsonPatch.dll
Microsoft.AspNetCore.Localization.dll
Microsoft.AspNetCore.Mvc.Abstractions.dll
Microsoft.AspNetCore.Mvc.ApiExplorer.dll
Microsoft.AspNetCore.Mvc.Core.dll
Microsoft.AspNetCore.Mvc.Cors.dll
Microsoft.AspNetCore.Mvc.DataAnnotations.dll
Microsoft.AspNetCore.Mvc.dll
Microsoft.AspNetCore.Mvc.Formatters.Json.dll
Microsoft.AspNetCore.Mvc.Localization.dll
Microsoft.AspNetCore.Mvc.Razor.dll
Microsoft.AspNetCore.Mvc.Razor.Host.dll
Microsoft.AspNetCore.Mvc.TagHelpers.dll
Microsoft.AspNetCore.Mvc.Versioning.dll
Microsoft.AspNetCore.Mvc.ViewFeatures.dll
Microsoft.AspNetCore.Razor.dll
Microsoft.AspNetCore.Razor.Runtime.dll
Microsoft.AspNetCore.ResponseCaching.Abstractions.dll
Microsoft.AspNetCore.Routing.Abstractions.dll
Microsoft.AspNetCore.Routing.dll
Microsoft.AspNetCore.Server.IISIntegration.dll
Microsoft.AspNetCore.Server.Kestrel.dll
Microsoft.AspNetCore.WebUtilities.dll
Microsoft.CodeAnalysis.CSharp.dll
Microsoft.CodeAnalysis.dll
Microsoft.DotNet.PlatformAbstractions.dll
Microsoft.Extensions.Caching.Abstractions.dll
Microsoft.Extensions.Caching.Memory.dll
Microsoft.Extensions.Configuration.Abstractions.dll
Microsoft.Extensions.Configuration.Binder.dll
Microsoft.Extensions.Configuration.dll
Microsoft.Extensions.Configuration.EnvironmentVariables.dll
Microsoft.Extensions.Configuration.FileExtensions.dll
Microsoft.Extensions.Configuration.Json.dll
Microsoft.Extensions.DependencyInjection.Abstractions.dll
Microsoft.Extensions.DependencyInjection.dll
Microsoft.Extensions.DependencyModel.dll
Microsoft.Extensions.FileProviders.Abstractions.dll
Microsoft.Extensions.FileProviders.Composite.dll
Microsoft.Extensions.FileProviders.Physical.dll
Microsoft.Extensions.FileSystemGlobbing.dll
Microsoft.Extensions.Globalization.CultureInfoCache.dll
Microsoft.Extensions.Localization.Abstractions.dll
Microsoft.Extensions.Localization.dll
Microsoft.Extensions.Logging.Abstractions.dll
Microsoft.Extensions.Logging.Console.dll
Microsoft.Extensions.Logging.dll
Microsoft.Extensions.ObjectPool.dll
Microsoft.Extensions.Options.ConfigurationExtensions.dll
Microsoft.Extensions.Options.dll
Microsoft.Extensions.PlatformAbstractions.dll
Microsoft.Extensions.Primitives.dll
Microsoft.Extensions.WebEncoders.dll
Microsoft.Net.Http.Headers.dll
Microsoft.Win32.Primitives.dll
Newtonsoft.Json.dll
NLog.dll
NLog.Extensions.Logging.dll
NLog.Web.AspNetCore.dll
System.AppContext.dll
System.Buffers.dll
System.Collections.Immutable.dll
System.ComponentModel.Annotations.dll
System.ComponentModel.Primitives.dll
System.ComponentModel.TypeConverter.dll
System.Console.dll
System.Diagnostics.DiagnosticSource.dll
System.Diagnostics.FileVersionInfo.dll
System.Diagnostics.StackTrace.dll
System.Globalization.Calendars.dll
System.IO.Compression.dll
System.IO.FileSystem.dll
System.IO.FileSystem.Primitives.dll
System.Net.Http.dll
System.Net.Sockets.dll
System.Numerics.Vectors.dll
System.Reflection.Metadata.dll
System.Runtime.CompilerServices.Unsafe.dll
System.Runtime.InteropServices.RuntimeInformation.dll
System.Security.Cryptography.Algorithms.dll
System.Security.Cryptography.Encoding.dll
System.Security.Cryptography.Primitives.dll
System.Security.Cryptography.X509Certificates.dll
System.Text.Encoding.CodePages.dll
System.Text.Encodings.Web.dll
System.Threading.Tasks.Extensions.dll
System.Threading.Thread.dll
System.ValueTuple.dll
System.Xml.ReaderWriter.dll
System.Xml.XmlDocument.dll
System.Xml.XPath.dll
System.Xml.XPath.XDocument.dll
It seems I found it myself.. There are CopyLocalLockFileAssemblies and CopyNuGetImplementations flags for .NET Core projects (i.e. new-style *.csproj files).
For .NET Core it's:
<!-- dependencies coming from the package manager lock file should not be copied locally for .NET Core and .NETStandard projects -->
<CopyLocalLockFileAssemblies Condition="'$(CopyLocalLockFileAssemblies)' == ''">false</CopyLocalLockFileAssemblies>
For .NET Framework it's set as "true" by some reason. Therefore binaries are so big in size.
Regarding xUnit projects - they are also overriding these flags and set them to true. Actually tests are working with having them "false" when you are using dotnet xunit or dotnet test, but it should be really "true" if you want to use xUnit console runner.
It doesn't really help me, but at least it explains why it happens..
It's really frustrating to have project just with one class, which is ~5kb, but Binary output is 16Mb.
I had a similiar problem with a little .NET core console app targeting net461 (which brought me here).
The Microsoft.Packaging.Tools.Trimming tool (now found here) sort of did the job for me at the end, as most of the copied assemblies weren't used by my application anyway. Just install the nuget package and insert following lines in the project file:
<PropertyGroup>
<TrimUnusedDependencies>true</TrimUnusedDependencies>
</PropertyGroup>
This will check for unused dependencies and remove them. Maybe that can reduce the number of DLL files a little.
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 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
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