I have an issue including a self-built library to a C#-project. I have created an own class library called ClassLibrary1 just to learn how to add libraries on Visual Studio 2019.
So I have written some simple code in a newly created .NET-class library project and have clicked on "create new solution" (directly translated from my german IDE-language. Maybe it's called slightly different) after writing the code. Back in the C#-project, I have selected the dll-file from bin/Debug/ of the class library's project folder.
After I have set the checkmark, the dll-file was shown in the solution-explorer under Assemblys like expected. But the issue I now have is that I still cannot use the ClassLibrary1.dll-file in the cs-file in this very project as I expected via the command "using ClassLibrary1;". It only shows me the error message "type- or namespacename "ClassLibrary1" not found" when trying to compile the C#-project and I don't get, why this is the case.
It seems like it has to be a very obvious problem but after some research on the internet and trying some things by myself still nothing has changed.
Thanks in advance for helpful replies.
The by far easiest way to manage a library is to use project references. Ensure that your library and the project that uses the library is in the same solution. Then right click the "references" and select "add Reference", go to the project tab and add a checkbox for the library. Read more about managing references.
You might also need to add namespaces for the classes you wish to use in the source files.
I would not recommend managing using file-references to lose dll-files, since it can easily become a hassle to manage. I.e. if you create a new version of the library you would need to build, and explicitly replace this file in all other projects and update all the references.
If you want to share libraries between multiple solutions the more popular solution would be to setup a nuget server. This solves some of the updating problems by maintaining multiple versions of the same library, and provides a nice interface to update references in all projects. But this is a somewhat more complicated solution, so I would not recommend this for new developers.
Related
I writing and open-source winforms app, and my program depends on another open-source project called ObjectListView.
ObjectListView is its own project in my solution and referenced as such, but its output is set as a .DLL.. It's just an enhanced ListView control. Is there any way that the project ObjectListView can be embedded in my own assembly without having to ILMerge or use some form of packer? (Defeating the purpose of an open-source project)
My initial thought was just to manually drop all the source files and whatnot into my own project, but that seems rather clunky and far from an idea solution.
PS; I did try searching for this but I didn't come across much that wasn't related to embedding DLLs into an output assembly.. Not merging projects like this. I apologize in advance if this question has been answered before.
If you don't want a separate DLL, and you don't want an embedded DLL, then perhaps a "Shared Project" project type is what you're looking for. The docs state:
A Shared Project does not get compiled on its own, it exists purely as a grouping of source code files that can be included in other projects. When referenced by another project, the code is effectively compiled as part of that project. Shared Projects cannot reference any other project type (including other Shared Projects).
While I don't think your project is exactly what it's intended for, I think it will work in your scenario.
See What is the difference between a Shared Project and a Class Library in Visual Studio 2015? for more information.
What is the use of the "References" list in my visual studio project? Why I can still get my project compiled and run it even though I remove all of the references?
When I create a new c# console project, it has a hello world template program, and the References list contains certain references from .Net I think. I removed all of them and the template program still work, why?
The template program has a bunch of usings that were in the references of the project so I thought if I remove all of them nothing will work, but the project still compiled and ran.
This seems to be a very simple question but I can not find anybody answering that online.
Say you need to create an image processing app. But you don't want to, or rather won't be able to create a JPEG encoder/decoder. So you will find a 3rd party library to do the encoding/decoding. And the 3rd party library needs to be put somewhere so that your project can find it. And that is the References folder (it is not really a folder).
Then you can use the 3rd party library's namespace in your own code. And it compiles. But if you remove the references, it won't because VS won't be able to find those namespaces.
If later you decide not to use this library, you will remove your using statement and all the relevant code. At this point, if you remove the references, your code will still compile because they are not used at all.
Ok to answer my question after some research and tests. There are indeed namespaces I can not reference if I don't add them into the References list, the ones that were still working after I removed references were the ones that are implicitly referenced by visual studio.
I have learned that from the links below.
https://learn.microsoft.com/en-us/visualstudio/ide/managing-references-in-a-project?view=vs-2019
https://social.msdn.microsoft.com/Forums/vstudio/en-US/92a0c975-e350-4d8d-af8e-36ec0ad6c95c/specific-purpose-of-mscorlib-dll-in-net?forum=clr
I'm quite new to C# and Unity so have mercy on me. I'm using visual studio.
I have what seems like a pretty common problem. Which is - i want to use functions i write across several projects in unity. I don't want to have to go search for the code in some folder, copy paste it into the new project, or fiddle with symbolic links or use .dll's. These are all not great solutions to the problem. Can't i just somehow create a class I can access across all my projects? Custom namespace perhaps that is not project specific? that i can simply just call at the beginning of wherever i want to use my homemade scripts.
If you don't want to build a custom DLL and the headache that comes with maintaining its versioning alongside Unity releases, consider building an AssetPackage. You can right-click in one of your projects and export a bunch of scripts that you want to be re-used in other places together as a package. When you start a new project, just load that package into it by dragging and dropping it.
If you're using git for your projects, you could add the shared code into a separate repository and add them to your projects as a git submodule.
You have 2-3 things to consider in this situation:
Ease of deployment
Whether or not you will update that code
Ease of update, if you will update it
If you just want to bring it in once, then Erik's answer should be simple enough.
If you want to keep things as an updated library though, you will need another method.
Symbolic links as you mentioned would be the best, or DLLs. However, with this, you'd run the risk of breaking your other projects if you ever modify the common lib from inside your project.
Another option would be to have a separate VCS (git, svn, etc) inside your project for your common code. This way you can update if/when you want, you can roll-back if something breaks, and you can even fork your "common" code to make a project specific change.
Since OP mentioned it, in this case, OP could specifically use Git Submodules or simply add a second Git project and add that sub-Git to the parent's .gitignore file
Even though Shared Projects have been around since Visual Studio 2015 (maybe as early as VS 2013 update2), I've only recently learned about them. Today I spent time trying to learn how to use them following a tutorial I found Shared Project: An Impressive Feature of Visual Studio 2015 Preview. However, the one thing the author did in that tutorial, which won't work for us, is he created the Shared Project and 3 other projects, all within the same solution. Of course, you can do that, but in practice we're likely to want to create a Shared Project in some solution, and then as time goes by, include that Shared Project in other solutions.
So what I did is instead of putting the Windows Forms application into the same solution as the author of that C# Corner post did, I created a new solution with a Windows Forms project in it, then I tried to add the Shared Project from the first solution. First, I tried adding the .sln file. That failed miserably. Then I tried adding the .shproj file to the second solution. That failed miserably as well.
Next I shared here on SO for ways of addressing this. I found 2 posts: Adding references in a shared (.shproj) project and How do I add a reference to a Shared Code project (.shproj) from another project. The second one gave me an idea. I decided I would simply add the Shared Project, from the first solution, to the second solution by clicking on the second solution within Solution Explorer, then doing a "Add Existing Project". That worked.
But I wonder, is that the way you're supposed to use Shared Projects? If so, it seems to me as though I could just as well created a simple class library in the first solution and then added that class library project to the second solution. Is there something about Shared Projects that make them inherently better to use, if you add the Shared Project to a different solution, instead of just adding a regular class library project to a solution?
A class library compiles into its own DLL and your original project references that DLL, whereas a project using a Shared Project will compile into a single assembly. One scenario I could think of with shared projects is that you can have single code base but has platform specific code sections marked by directives.
There is a good video on this subject even though it's being explained in the context of xamarin they do a good job i think.
https://www.youtube.com/watch?v=G5ov0gLZWgQ
Personally I I would always go with PCL (portable class lib) rather than SAP (shared project). I use shared code projects as documentation container in my projects. The project green icon stands out really well. I keep everything there from markeddown doc files to stored procedures and etc.
When I need to add a reference towards a library, I've always been told to use the "add existing project" method, and referencing the project itself inside my solution.
But here in my new company, the use another method. They have a server which holds the compiled dll's, and keep versions of them so they can reference older versions when a change is too important to refactor older apps.
While I find this system really complicated (I guess there is a lot of work if a program pointing an older version of the dll is updated and needs some changes in this dll), they seem to find it pretty convenient.
What are the best practices for this? Linking the dll directly? Linking the project? And why? Any information is welcome!
Thanks in advance !
I usually take a copy of the compiled dll (if the source project is not available or if I don't need the source) and put it in a folder inside my solution, and then reference that. I check it in to source control along with my project.
I am of the opinion that you should be able to check out a project and build it directly from source control without having to go hunting dlls etc.
The Add existing project method is useful when you want to reference a library project which is develop side by side and you want to test/use it's types and methods and this (Add existing project) method will not be used to add the reference of pre-compiled (dll) files.
Read Project Reference (MSDN) article.
You would include it as a Project when you want to simultaneously work on the library. And that would happen mostly for small(ish) libs that will be distributed with your program (bin folder).
When an assembly is (going to be) installed in the GAC, and thus has its own release cycle, it makes more sense to reference the binary only.
Several combination of the above are possible too.
Adding Compiled dlls is mainly when the code is more or less locked (Architecture level code ) which you hardly ever changes
eg
1) communication layer(remoting/wcf)
2) Generic Gui layer (Wizards/dialog boxes)
3) Security layer (azman stuff)
you only need to change when your product is going to another direction say it uses to use .net remoting as communication now it will be using WCF
Using projects as reference when you are frequently changes referenced projects
also Visual studio works out nicely order of building the projects.
Although your company's approach is probably not very common among Microsoft developers, it is used rather successfully in the Java world. In the long run it is probably better controlled than any alternative, but without a fair amount of support scripts/programs (which, for instance, update projects/solutions automatically when needed) it can easily become unmanageable. In the Java world it is directly supported by tools such as Maven.