I was wondering if it is possible to create a DNN module that references a compiled business layer, instead of using just the data provider approach that's included in the default project. How would such a project be deployed? Just copy the compiled assembly that I'm referencing into the website bin folder?
Yes, you can reference assemblies in the bin from your module's project.
Related
I have created a nuget package containing a DLL that I want to share with multiple applications. I want to add this package to applications without setting a reference to the DLL. I am using dependency injection to load this DLL or a test DLL at run-time.
By default, nuget automatically sets a reference to all DLLs contained lib during installation.
Is there any way to configure the nuget package to not set a reference to the DLL when it is installed into my project?
Explicit assembly references. Although if your dll is loaded entirely at runtime (using MEF or Assembly.Load or something similar), then the build system might not copy the dll to the project's output directory. Note these docs are only correct for packages.config projects. I have a PR to improve the docs to explain how to do the equivalent thing for PackageReference.
I have a project that targets two different operating systems/frameworks:
net461 on Windows and
netcoreapp2.0 on OSX
I'm trying to figure out how to correctly package this for NuGet. According to this post I should be able to package them like this:
/runtimes/win/lib/net461/myassembly.dll
/runtimes/osx/lib/netcoreapp2.0/myassembly.dll
By when I add the NuGet package to another project, the packaged assemblies aren't added as references to the target project.
Then I read somewhere that you also need to add reference libraries to the /ref folder so I tried this:
/runtimes/win/lib/net461/myassembly.dll
/runtimes/osx/lib/netcoreapp2.0/myassembly.dll
/ref/net461/myassembly.dll
/ref/netcoreapp2.0/myassembly.dll
In this case the assemblies get added as a reference to the target project and I can build it, but the required assemblies aren't copied to the output folder.
The documentation on all this is extremely vague and I'm fairly lost.
What am I missing?
Associated NuGet Issue: https://github.com/NuGet/Home/issues/7316
Update: I've put together a sample project that demonstrates what I'm trying to achieve. In particular see the bottom of the readme, titled "NuGet Packaging".
This is what I've finally figured out/guessed (because as best I can tell there's no official documentation for some of this)
Files added to the /runtimes folder aren't automatically added as references to the target project.
The /ref and /runtime folder should be used in conjunction with each other and only for the .NET Core target. As best I can .NET Framework targets apparently don't support these folders.
The /ref folder is for compile time references and anything added here will be added as a reference to the target project.
Assemblies in the /ref folder don't need to have an implementation - every public API could just throw a not implemented exception. In practice however you typically just take a copy of one of the implementation assemblies and declare it as the compile time API.
I've read (but haven't tested myself) that assemblies in the /ref folder must be "Any CPU" builds. You can use CorFlags utility to patch an implementation assembly for this if necessary.
The /runtimes folder is used to provide an implementation assemblies for any references included in the /ref folder. These assemblies are used at runtime and during deployment.
The /runtimes folder can include additional assemblies that are only required at runtime and don't need to be seen by the client project. These additional assemblies won't be included as references in the target project but will be available for run/deployment.
As mentioned by others, the files in the /runtimes folder aren't copied to the output folder of the build. Instead config files are placed there that tell the runtime how to locate the /runtimes files from the NuGet cache.
For .NET Framework targets (ie: net461) just use the /lib folder as there's no other runtimes for .NET aside from Windows anyway.
Putting this all together, my original example, should have looked like this:
/lib/net461/myassembly.dll (net461/Windows Compile and Runtime)
/runtimes/osx/lib/netcoreapp2.0/myassembly.dll (netcore/OSX Runtime)
/runtimes/win/lib/netcoreapp2.0/myassembly.dll (netcore/Win Runtime)
/ref/netcoreapp2.0/myassembly.dll (netcore/* Compile Time)
I spent a fair amount of time trying your project on OSX in both Visual Studio for Mac and VS Code. I'll try to stick with factual observations without getting into "why don't you do X instead".
The runtimes/{rid}/lib/{tfm}/*.dll paths look ok
target="lib/{tfm}/..." assemblies are automatically referenced, runtimes/... are not
Using target framework of netstandard seems like it would make your package work in both netcoreapp and netstandard projects (e.g. use target="lib/netstandard1.6/..."). Compare with this
runtimes/ seems to be intended for platform-dependent assemblies you'll load at runtime. For example, 32/64-bit native assemblies in runtimes/win-x64/native/ and runtimes/win-x86/native/) loaded with AssemblyLoadContext (another post by McMaster)
Using separate slns for Windows and OSX, or separate platform-specific projects that reference platform-agnostic projects (like Xamarin) would obviate some of the configuration wrangling
I found no documentation on target="ref/...", but you can add Explicit Assembly <references> (inside the nuspec <metadata> block)
Packaged assemblies won't appear in the output directory, but when prepared for distribution with dotnet publish they'll be included:
.NET Core and .NETSTANDARD don't copy dependencies to output directory, they are mapped using deps.json which points to relative paths from local NuGet cache.
This has been a very useful thread to get more information and hints on how to create a NuGet package that references native DLLs, and is consumed in both .NET Framework as well as .NET Core / modern .NET libraries / applications.
My experience so far has been that if this library (let's call it library A) only targets .NET Standard, consuming this library in a .NET Core / 5.0 or 6.0 application does lead to the native assemblies being pulled in correctly from the runtimes folder. In a .NET Framework 4.7 application however, this does not appear to be the case. Unless the runtime is explicitly specified when compiling, e.g.:
dotnet build ... --runtime win-x86
When using library A in a .NET Core or .NET 5.0/6.0 application however, this runtime identifier is not required - all runtimes are made available and the right one is selected at runtime.
If you want library A to be consumed in applications that also target .NET Framework, and you don't want the user to have to specify the runtime explicitly, then it seems to be necessary to:
Target both .NET Standard and .NET Framework
Ensure that the native assemblies end up in the following folder structure in the NuGet package:
"lib/{tfm}/..."
While the .NET documentation referenced by tm1 earlier here talks about how to get this to work using nuspec files, it is less clear how to do so in the SDK .csproj format. I managed to do this in the NLoptNet project, see the relevant .csproj file here. Final relevant point (in addition to the two bullets above):
Use "<None Include" rather than "<None Update" to add the native assemblies
So far - this works, but there is one quirk - as you can see here it generates warning MSB3246 when consuming library A in a .NET Framework application. See also this Stack Overflow post. This leads me to believe that maybe the above is not the right approach, and therefore to some questions:
Is this the intended way to consume library A in .NET Core, modern .NET and .NET Framework applications?
Should one always specify the runtime identifier when using dotnet build / dotnet test?
Can you try to target .NET Standard 2.0 instead of net461 and netcoreapp2.0? Libraries built against netstandard2.0 should work with .NET Core 2.0 and .NET Framework 4.6.1: https://learn.microsoft.com/en-us/dotnet/standard/net-standard
Are you using the new csproj format? If so it has built in support for multiple target frameworks.
For example running dotnet pack against a .csproj file with this content:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net461;netcoreapp2.1;netstandard2.0</TargetFrameworks>
</PropertyGroup>
</Project>
will result in a .nupkg that works for .NET Framework 4.6.1, .NET Core 2.1 and .NET Standard 2.0.
Various trick can then be used to include specific parts for each framework depending on what's available.
I'm trying to solve the same problem.
The solution proposed by you works fine, but there is one question ...
The case of Win and net46 is clear. And now I need to add a reference to the assembly in the project for a netcoreapp for the Win and for Linux. The problem is that this is a DIFFERENT assembly with the SAME name. Those my package looks like this:
/lib/net461/myassembly1.dll (net461/Windows Compile and Runtime)
/runtimes/ubuntu/lib/netcoreapp2.0/myassembly2.dll (netcore/Ubuntu Runtime)
/runtimes/win/lib/netcoreapp2.0/myassembly1.dll (netcore/Win Runtime)
/ref/netcoreapp2.0/???
Update: Actually, the myassembly1.dll and myassembly2.dll are both called myassembly.dll. But to show that one is assembled for Windows, and the second one for Linux, I will leave here such a name.
The most interesting thing is that I tried to put any assembly in the folder ref, and it works on both Windows and Linux.
This version works on both systems
/lib/net461/myassembly1.dll
/runtimes/ubuntu/lib/netcoreapp2.0/myassembly2.dll
/runtimes/win/lib/netcoreapp2.0/myassembly1.dll
/ref/netcoreapp2.0/myassembly1.dll
And this too
/lib/net461/myassembly1.dll
/runtimes/ubuntu/lib/netcoreapp2.0/myassembly2.dll
/runtimes/win/lib/netcoreapp2.0/myassembly1.dll
/ref/netcoreapp2.0/myassembly2.dll
But I think this is not right and I was wrong somewhere.
I added a reference itextsharp.dll to my plugins project, when running my plugins using plugin-registration tool I get this exception:
Could not load file or assembly or one of its dependencies. The system
cannot find the file specified
I tried removing the ref and adding it again, cleaning and then adding it to my project from different places.
Is there restrictions in plugin registration tool about adding non crm dlls? why ? how to solve it?
This is not going to work - you cannot reference external assemblies from CRM plugins that are registered in database. If you want to do this, you will have to merge your external dll with your plugin assembly. You have to remember that adding assembly as reference is not automatically making your referenced assembly available for your base assembly, therefore if you register your plugin assembly in CRM, system is not going to "magically" find somewhere your external assembly (in your case - "itextsharp.dll"). If this is not Online system, you can add your assembly to GAC, or register all your assemblies on Disk instead of database (not recommended approach). If you want to register them in database, you will have to merge everything in one assembly using ILMerge for example.
You can't reference something in a plugin unless it's in the bin of the CRM.
To make it work you need to ILmerge your reference with the plugin. Install this package in your project: MSBuild.ILMerge.Task. Then build. It will work instantly. The package will merge everything in the bin after the build. So make sure every other references are marked "Copy Local = false". Otherwise, you'll have a crazy big assembly.
Finally, Microsoft released a solution for this. You can build a nupgk file and register dependent assemblies.
Here are the white paper and my post about this;
Microsoft : Microsoft White Paper
My summary: Here is the link
I created a module to share code across a couple of projects.
I created a GWT project: Framework. I then created a module com.framework.Framework within the project. The Framework project contains both client code, in the com.framework.client packages, and server code in the com.framework.server packages.
I try to consume this by
- Adding the project to the Java Build Path
- Adding to the module's definition
When I run the consuming project, I get NoClassDefFoundErrors for Framework classes I use in the module's server code.
What am I missing?
If I jar up the Framework project's WEB-INF\classes contents and put it into the consuming project's WEB-INF\lib folder, as well as add it to the Build Path it seems to work, but I don't see a way to keep the framework classes up to date in the consuming project(s).
Please make sure that you create gwt.xml file via menu New->Module, and in this gwt.xml file, you must declare your entry point class.
I have a solution with about 10 different projects - I have a single class library that I am using in quite a few web projects. The problem when I am going to deploy these projects...they are going to have their own bin directories and hence references to this library...so i would need to update the reference on all 9 places/projects whenever i updated the class library....is there way that i could have like a common root bin directory where all the projects could refer from and that when i change the class library it automatically will be updated in all 9 projects since they are reading from a common bin directory ?
You could install the common library to the GAC (Global Assembly Cache).
http://support.microsoft.com/kb/815808
After you install the DLL to the GAC, you can change the reference in each of your web projects to point to the GAC'd version of the library.
Updated:
Your other option is to load the DLL programmatically/dynamically at runtime (in all web projects that require it). This should only be done under special circumstances.
http://www.c-sharpcorner.com/uploadfile/sridhar_subra/dynamicassemblymethod10132008214835pm/dynamicassemblymethod.aspx
Off the top of my head, the most common "special" circumstance would be if you're application has some sort of plug-in architecture. As you can see in the link above, loading assemblies takes a little work.
Honestly, if you're deploying to a production environment, you should be able to use an MS installer project to deploy your DLL to the GAC. The command-line tools are more for development purposes.
Right click on a project, go to properties, under the build tab, set your output path.
Does that answer your question?