So we have a ASP.net MVC 4 solution that is composed of the 3 projects BusinessLibrary.UI, BusinessLbrary.Domain, BusinessLibrary.Tests
We use nuget to manage all of our libraries like json.net, entity, etc. But we also have some private libraries that we have added. What is the best way to manage of the private libraries we have. I would like to be able to have a new developer to get all the DLL's associated with this project when they start.
Ive read that I could create a library or lib folder, and then just reference the DLL's to there. But should that be checked in with the Project' s Source Control then? Would I only want to copy over the non-nuget private libraries. Is this the best way to go?
What is the standard practice for situations like this, how should I be storing my private libraries?
Personally, I create a dependencies folder at the solution level. I put all non-NuGet libraries that I reference there. When I add the reference, I'm sure to reference the assembly from the dependencies folder. Make sure you add the dependencies folder to Source Control.
That way any developer pulling down the solution from Source Control will automatically have the correct version of all of the dependencies.
Optionally you can install your own NuGet server and place your libraries there after successfull server build of those libraries
We create a library directory, add the assemblies there and use relative paths to reference them. We also check in this directory, so every team member immediately has the newest assemblies.
Another option would be to setup a private NuGet feed (such as MyGet) and publish your assemblies there as packages.
In our project we created lib folder for private dll's and checked in it to TFS along with source code. NuGet packages are added to TFS automatically.
Related
I created a class library project using C# and .Net.
In this project I used two external dependencies(to be more specific: Microsoft.Win32.Registry(4.6.0) and System.Data.SqlClient(4.7.0) Nuget packages).
After I build this project, I can see the generated DLL file under /bin/debug folder.
Now I want to import this generated DLL in another project and consume its methods. Once imported and I run this project, it complains about not being able to find those two external dependencies I had in class library project.
As a temporary fix, I can import these two missing references in this project and it will work fine and as expected. But this is not what I want(and I guess is not a clean solution as well).
I want to know why the dependencies of class library project is not reflected in generated dll file? And is there any way to fix this?
Many thanks for your help.
If your class library is in the same solution or source control repository as the app that's using it, you should use a project-to-project reference, rather than referencing the assembly directly. As the docs say, this way it automatically detects changes to the class library when you compile the app, but what the docs didn't say is that dependencies flow though as well.
Otherwise, as Lance Li wrote, you should create a NuGet package from your class library. Unfortunately there's a bit of a barrier to get started. Creating the package is easy, but then you need to publish the nupkg file somewhere. For early development (before the package is ready to be shared), the easiest option is to use a local file feed. You'll then need a nuget.config in the app that will use the package to add that local feed as a source, then you can install the package in your consuming project, which will bring dependencies.
As you can see, for development, this is slow and difficult because if your consuming app finds a bug in your package, or if you're trying to develop a new feature in both the consuming app and class library at the same time, it means every time you make code changes to class library, you need to increment the version number, pack a package, publish the package, then update the package version in the consuming project. It's far, far easier to use a ProjectReference which lets you simply edit code, compile, run. Nothing else to think about.
See this, the way you reference that assembly is not a recommended way when both the projects are in same machine.
You're using the file reference(Add reference => browse...). And that's why you have to import these two missing references in this project manually.
So I suggest you add the project reference, if both the two projects are in same solution, you can right-click current project=>add reference=>project tab find that assembly you need.(instead of browsing...)
If the referenced project is not in same solution. Right-click solution in solution explorer=>add existing project to import it. Then add project reference.
So, I'm having trouble adding a git project to my net Core solution, and after spending hours trying to figure this out and being uncapable of finding a solution online, I decided to ask here.
I have a forked github repo (link) in which I modified some files to suit my needs, but I simply can't seem to get it to work with my current project.
The problem I'm having is that normally, when I want a package for a .NET project, I usually simply go to nuget and fetch the necessary dependencies. This is usually very simple and straight forward. But now that I have these modified files, I'm unsure on how to proceed.
I have tried adding it as a submodule, but after I built the project, I got an exception saying that the dll could not be found.
Then I've tried adding the dll itself as a reference, but the ImGui.dll depends on a C dll which couldn't be found then (nor added to the project).
Finally, I've tried adding the csproj as a project of my solution, but that didn't work either
Do you know what am I doing wrong here? Am I missing a key piece or is it just something obvious I'm not seeing? It can't be this hard to get it to work
From the look of it, that repository produces a DLL (output type Class Library). So modify it to your liking, and use the sample program build (ImGui.NET.SampleProgram) to test your changes. Once you're happy, build the DLL project (ImGui.NET) and use the resulting DLL as a Reference in your own app.
In Visual Studio:
Solution Explorer>YourApp>References>Right Click>Add Reference...>Locate your DLL
This means you should also keep track of your modifications to the ImGui.NET project itself, since you may/will be required to maintain this in the future.
Hope this gets you started -- update your question with more specific issues once you're underway.
Edit:
Like #CoolBots mentions, I probably misread your question. Seems like the build depends on cimgui.dll, which you can hotlink from the ImGui repo along with your custom DLL. In fact, the demo app is using cimgui.dll, cimgui.dylib and cimgui.so. Regardless of linking method, you want the files to copy into your build folder. I don't believe subfolder /bin is necessary.
You can find all the cimgui dependencies for various operating systems in the ~/ImGui.NET/deps/cimgui folder.
The demo also utilizes NuGet packages Velrid and Velrid.StartupUtilities.
Depending on your own codebase, you may or may not require these NuGet packages along with the aforementioned class library.
I am trying to code an application in C#.NET Core that can be extended using MEF. Currently, I am able to do that without any issues with libraries, that have no dependencies or have the same dependencies as the host app (so dependencies are already loaded). But, if I want to use a library with a NuGet reference, that is not used by the main app, the loading of this library fails on that reference.
How can I force the main app to load the missing NuGet dependency, if it tries to load an assembly with such reference? It seems to me as a pretty common use case, but I am lost here and cannot find a way out. Thanks.
For reference, I am posting the portion of the code.
[ImportMany]
private IEnumerable<Lazy<IService, IServiceMetadata>> _asrServices;
...
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new DirectoryCatalog(Path.Combine(Directory.GetCurrentDirectory(), "Services")));
CompositionContainer _container = new CompositionContainer(catalog);
...
foreach (Lazy<IService, IServiceMetadata> _service in _asrServices)
{
var _serviceInstance = _service.Value // here the loading fails
}
Jiri
.NET currently has two build "systems". One is the original project files, that import Microsoft.Common.props and Microsoft.CSharp.targets (assuming it's a c# project) and lots of XML in between, that has been around ever since .NET was first released, apparently in 2002. Since .NET Core was made generally available in 2016 there has been a new project system generally called SDK projects because the way a *proj file references the build system is though an Sdk element or attribute in the msbuild xml. Although it's off-topic, because there's a common bad assumption, I want to point out that although SDK projects were created for .NET Core, you can target the .NET Framework from SDK projects.
With the original project files, when you build, all the projects references get copied to the output directory. However, with SDK projects, only the project's assembly is copied to output (I'm not sure, but I think even content set to copy to output doesn't actually get copied on build). In order to get everything in a single directory, you should use the dotnet cli's publish command.
So, if you have a build script that builds your project and copies all the plugins somewhere, you should add a dotnet publish step to the script for each plugin using the SDK style project file.
If I add a NuGet package reference to DLL project MyLib (i.e. output type Class Library), the package manager sometimes creates an app.config in the project (for example with a bindingRedirect) that gets built as MyLib.dll.config. Microsoft.Owin 2.1.0 does this, for example.
When my Windows desktop application loads MyLib.dll, it ignores the bindingRedirect in MyLib.dll.config, and I get a FileLoadException. I can fix the problem if I manually copy the bindingRedirect to the app.config for the EXE project.
Is this manual copy-paste between app.config files really the only way to get a NuGet bindingRedirect to work?
It seems terribly tedious and error-prone given that NuGet is supposed to handle dependencies automatically.
It is the only way: app.config files in Class Library projects are essentially just sample code that you can copy into the main application's config file if needeed.
In the case of bindingRedirect - I would expect it only to be necessary in two cases:
if you have multiple dlls accessing different versions of the MyLib assembly. In which case, you need to make an explicit decision as to which version you're going to use.
If your main application's assembly contains configuration elements that reference an older version of the MyLib assembly. In which case you can do one of:
Update the versions in your main configuration file
Add a bindingRedirect to the main configuration file
Add the Nuget package to the main application project, in which case it will presumably add the bindingRedirect for you.
All that package specific config file does is show you the configuration that is specific to that package. You may or may not want to put it into your actual config file, you may need to tweek it for your purposes (EntityFramework or log4net are good examples of that). In the case of installing the package into a class library a config file makes no sense at all, that config needs to be moved into the appropriate executable app.config - how could that be automated.
Before nuget you would download the dll from somewhere and then follow the instructions on how to set up the necessary configuration. This is definitely an improvement on that.
So in summary, yes you do need to copy it if you need it and it does make sense.
There is a better way. I just needed to add some local project references before adding the NuGet package reference.
When I originally added the Microsoft.Owin NuGet reference to MyLib, I had not yet added a MyLib reference to MyApp (aka the EXE project). With the MyLib reference in MyApp, I uninstalled the Microsoft.Owin NuGet package, then added Microsoft.Owin back to MyLib. Bada-bing-bada-boom. The bindingRedirect was automagically added to MyApp's app.config file.
So, when creating a new Class Library, one should apparently add new-library references to existing projects before adding NuGet package references to the new library.
I'm building a .NET DLL Class Library which depends on other libraries such as log4net.dll - where should I put these DLLs when packaging up my DLL? Is there a way to automatically include them inside one super-DLL? Should I just ship all the DLLs in a single bin folder?
Just ship them all in a directory with your dll (assuming you're talking about a binary distribution - in a source distribution I'd have a "lib" directory containing your dependencies).
Don't forget to check whether or not you need to also supply licences, directions to get the source etc.
I wouldn't be tempted to try to merge your class library with the dependencies, personally.
You need to check the EULA and other licenses attached to those other DLL's first. Some may restrict how their DLL libraries are redestributed. Assuming no issues with that, you can either compile them all together as one big DLL, or create an installer (or a simple zip file) that will install all the associated DLL's in their intended destination.
in your solution tree, have a folder called 'src' for all yoru source code and one called 'lib' for libraries such as log4net, your homemade dll library, and any other libraries.
You should take a look at ILMerge. I linked a blog that shows an usage of ILMerge
Leveraging ILMerge to simplify deployment and your users experience
Not sure how you are deploying your solution, but don't forget that in order to sign your class libraries you'll need to have your 3rd-party .dlls signed. This alone might require you to merge all your references.