I have a solution that has a project that has a class that I'd like to share with another project in the same solution.
This class depends on a library that was pulled in from nuget.
Because the second project hasn't pulled this same library from nuget, the class execution fails (despite the second project depending on the first).
Up to this point, I've just been going and adding the same nuget packages to multiple projects.
This seems terribly unwieldy as when I need to update one project, I have to remember to update them all, or depend on tests, which seems like a great opportunity for bugs to slip through the cracks.
How can I go about sharing these dependencies between multiple projects in the same solution?
I create a sample solution based on your description, I found the dependencies nuget library could be found automatically in other projects that reference Class1 project. But if I set the Copy to Local property as false for the nuget library in Class1 project references, I will get an error message about could not find the dependencies when running other projects.
So please check the Copy to Local property for the nuget library in your Class1 project to confirm it is set as True.
Related
I'm a newcomer to .NET world, and at this point I'm super confused about the packages, references and how to reference them in my c# project.
I have 3 project in my solution:
DataAccess - which contains the logic for accessing data, the mapping between DTOs and entities, etc.,
DataAccessTest - contains unit tests for DataAccess project,
Service - wraps the DataAccess project into a Windows service.
Now, DataAccess project references AutoMapper (among others) to help with data transformation. It's included in <PackageReference /> element in the csproj file. It seems to be working fine when I'm doing dotnet restore, however dotnet build fails when trying to resolve the namespaces! The same goes for JetBrains Rider - it doesn't find the namespaces until I explicitly reference them in <Reference>!
Not sure if related, but the same goes for the dependent projects. For example, DataAccessTest references the DataAccess project - so that the test will run. However, it still requires adding the transitive dependencies (for example AutoMapper), on top of the project reference.
Is this the intended behavior? Do you need to keep both <PackageReference> and <Reference> for project to compile correctly?
In C# you Have to take care about referencing to other projects. if one project has been referenced to other project, the other project couldn't use or reference to first project. if you did, it will gives you compilation Error.
You need to install Nuget packages for each project that references methods in that package. So, if only your DataAccess project requires AutoMapper, it should be sufficient to add the Nuget package to that project. The solution is not much more than a wrapper around a bunch of projects. You should be able to publish a project separately. The project will take care of its own dependencies. It is hard to find out what goes wqrong. It may be helpful if you create a small testproject, e.g. create an empty console project and a DataAccess Library. Then you add a Nuget package to your DataAccess library and copile all stuff. In this way you can try to find out what is goning wrong. Make sure to install the Nuget Packages for the correct project (I got this wrong several times before I discovered how it really worked).
This is the basics of the problem I am having (of course it is oversimplified for the sake of the question):
I have 2 projects in a solution stored in mono-repository:
Project1 - outputs a library
Project2 - outputs an executable
When Project2 references Project1.
I would like to move to multi-repository where Project1 will be stored in different Repository from Project2.
Project1 will output a nuget package and Project2 will reference it instead the project itself.
The issue I am facing: in current situation (mono-repository) when during development I introduce a feature in
Project2 that also requires a change in Project1 it is not a problem. If there are problems I can discover it
during development time.
In a new way (multi-repository) I first need to make a change to Project1, create nuget and push it to nuget
store, then update reference in Project2. If I would have problems in Project1, I must go back to Project1,
fix the issue and push it again, update reference in Project2 and so on. Also, losing the benefit of debugging
both projects.
Is there a solution to this approach? To focus my question: if I have source codes of both projects on my dev machine,
is it possible somehow to instruct Visual Studio to use source code instead of referenced Nuget for debugging?
Hope I explained it right and clear as possible...
If you have two different projects and both of them are in different repositories, you could add the library as a submodule of the first project. I'm assuming you're using git. You could do this simply by:
git submodule add <link for the other repo>
In visual studio you just add the project to the same solution and then reference library from the executable. I'm not sure if that would do the trick for you, but I hope that works.
We have the exact same problem in our company.
This is 2 part problem.
First part is to have both repositories near each other... There are more options, we were deciding between these 2:
git submodule
meta repository (it is a compromise between mono-repository and multi-repository) you have 2 repositories you want to connect, so you create 3rd repository as a meta-repository via https://github.com/mateodelnorte/meta
Second part is how to connect those 2 repositories so that they are debuggable, but still apart each other... We though of these 3 ways:
new .sln in meta repository that will reference both projects (this didn't cut it, because we already been in a position when we had multiple .sln files and maintaining them is not that easy, because when you add some project into one, you have to add it to the other solutions and this goes sideways really quick)
using Reference and PackageReference with Condition - locally for debugging when .dll is build in ProjA then the ProjB would use "Reference", if not the ProjB would use PackageReference => this was our main solution to our problem until we did it like that... (Because we have more than 2 projects ProjA -> ProjB -> ProjC.. The problem here was when it was built locally, referenced via Reference DLL, then ProjA was not visible from ProjC, but when built via CI and referenced via PackageReference, then ProjA was visible from ProjC)
using only Nugets - Every build of ProjA it will create nuget locally (pre-release) and in ProjB, we would reference that via wild-cards. This works, until you make a second change into ProjA, because ProjB will cache that nuget in C:/Users//.nuget/packages :( so when building ProjA and packing the nuget we clear the newly built nuget from this packages folder. You have to restore ProjB every time you make change into ProjA, but this is where we landed as a final solution for now.
So the final solution for us is:
meta-repository for like 5 other repositories
for debugging we use locally built nugets with constant version of "major.minor.patch.65534-local"
for CI we use the same nuget packaging but we override the local version with
feature branches "major.minor.patch.build_number-branch_name" (having -something after the version makes that nuget pre-release)
master/main branch "major.minor.path.build_number"
I thought this would have been a question already asked many times, but I can't find it.
We are developing applications and have multiple shared assemblies which are used by multiple targets. When I'm creating a new application I'll probably use such a assembly (eg Framework) and reference it in my project. All fine here. However, when this Framework assembly uses for example the Model assembly, I'm not forced by Visual Studio to reference it. As long as my code doesn't touch any Model types, it will compile fine without a reference.
At runtime, it does require the Model assembly. When releasing this application there is no problem, as I just include all the required references in my installer project.
The problem arrizes when I try to debug the application. The bin folder won't have the Model assembly as it's not referenced.
The question
Is there a best practice to solve this "reference of a reference" situation?
Solutions we've come up with
Add the Model as a reference
This feels wrong, we pollute the project
Include the Model project in the solution and add as project reference
This feels even worse (polluting the solution)
Add post-build step
Could be a solution, but doesn't feel that right either.
The best solution for this is to package your Framework or Library assemblies (or sets) with NuGet. You can then use NuGet in Visual Studio to take care of all these references. This works great, even when using nested dependencies.
NuGet is fully supported and integrated into Visual Studio. It is very easy to host your own package repository (that can be as simple as pointing to a file share with packages).
You can host a private on-site repository for your own (internal) pacakges. That's what most shops do. You can combine that with one or more public NuGet repositories for public things as Log4Net etc..
And while it may seem to take some time to get this up and running (which is relative, try to just use a public package first just to get the hang of using NuGet first), you get a whole lot of benefits as well. For example, you get support for versioning your libraries out of the box.
At my company we've had this problem for years, and we used to build and check-in library assemblies (50+) into source control, and dragging that around across branches. Since we've switched out approach to using NuGet, this problem just gone away for us. Never looking back to that anymore.
A reference to another project does not necessarily need to be a Project reference. In your example, reference Model as a Bin reference within Framework. This way a pre-built Model will be included with the build of Framework.
This has probably been posted before, but I'm not sure what search terms to look for!
Quick explanation.
I have code that is shared between a few projects. This code is still work-in-progress itself. The issue is that whenever I need to update this code for whatever, I don't want to have to do it 3 times, this will become a nightmare.
Is there a way to add it to a project, without copying it into the project folder?
i.e. I want the shared class to be linked into my 3 projects as
C:\code repository\sharedclass.cs NOT \eachproject\bin\sharedclass.cs
Do I have to create it as it's own library project? It would be much better if the compiler could compile it as 'external' code.
Cheers.
As others have said, you can simply right-click on your solution in the solution explorer, select Add > Existing Project, and browse to the common project's .csproj file, and it will be included in the solution from its original location.
There are two problems with this however, which may or may not be an issue, depending on the size of your team:
The common project will be included in each solution with a relative path to the solution file (i.e.: ...\CommonProject\Common.csproj). This means all developers have to have the same working file structure or they will get errors when they try to open the main project.
In the scenario that the common project is referenced by multiple projects (say two - A and B) and a developer working on project A has to make changes to the common project as part of their task, there is no way for that developer to know if the changes they have made will break project B without them actually checking out project B and compiling it. As more and more projects reference the common project, the risk of this happening increases to the point where it becomes unmanageable.
Again, as others have said, there is no 'correct' way to do this. However, the approach I have taken is as follows:
Use continuous integration such as Cruise Control to manage the building of the projects and put the common project as a standalone project on the server.
Create a directory under your source control to house built common DLLs. Have this directory checked out on your build machine and whenever the common project builds, it copies the output DLL into the DLL folder and commits these changes to source control.
Use environment variables on all developers' machines and the build server to control the location of the common DLL folder and reference the DLLs using that variable rather than the hard-coded path. (i.e.: rather than C:\Source\MyCommonProjectDLLS\Common.dll, use $(MyCommonLocation)\Common.dll with the variable 'MyCommonLocation' set to C:\Source\MyCommonProjectDLLS)
For any project which references the common DLL, set up a CI trigger on the build server for that project to watch the common DLL folder. Whenever changes are committed to it, the build server should then build all consuming projects.
This immediately lets you know if you are committing breaking changes for any other project. The only drawback is that, in this model, consuming projects are forced to take updates to the common DLL as soon as they are made. An alternative is to version the Common DLL from the source control revision when it is built, and place each version in its own sub directory under the common DLL folder. So you would end up with:
Common DLLs
-1.0.0.1234
-1.0.0.1235
-1.0.0.1236
And so on. The advantage of this is that each project can then choose when to take updates to the common DLL by simply referencing the new version of the code. However, it cuts both ways as this can mean that some projects are left with older versions of the common code for longer than they should, which can increase the work involved when the time comes to finally bring in those changes.
Yes.
You can add a project from anywhere on your hard drive to a solution. So put the shared code into a class library and add that to your three projects.
Microsoft has been supporting an open source project which comes built into VS now, its called NuGet, you can output your shared project as a nuget file and consume it in your other projects.
It will actually deploy all the files you specify in the package upon build.
This is how .Net supports dependencies now. You will notice that even things like EF come through NuGet packages. You can even host it for free on places like MyGet.org I use this and it works quite well.
http://nuget.org/
I use git submodules to achieve this.
Create a new git repository for each module (project) that you want to share between solutions. I usually also include unit tests for that project in a separate project but in the same git repository.
Add a submodule to the git repository of the solution that will use the shared code. Adding a submodule creates a link to a specific commit of an external repository. When the code in the submodule is updated you will be able to pull the updates to your parent solution, which is essentially the same as updating the reference to the submodule commit. I find that the process is easier to visualise using an app like SourceTree.
Adding the submodule and pulling the latest commit will create a copy of the shared project inside the parent solution folder. Import the project into the parent Visual Studio solution by right-clicking on the solution and selecting "Add existing project".
Add a reference to the shared project in the other projects that will be using it by right-clicking on the project and selecting "Add Reference" and finding the shared project in the "Solution" tab.
Now that the shared project is included in the solution you will be able to push and pull changes to the submodule and these changes will automatically be incorporated into the solution. You will also be able to see the changes in other git repositories that reference the submodule.
Yes, put the code which need to be shared in a separate class library project, build it and reference the DLL created from this build into your other projects.
It is better to extract common part into a separate project library and add reference of this project to all the solutions/dependent projects.
Otherwise you can Add code/file/item as Link.
I have a class library project contains common codes that used in my projects and i use subversion as source control.
i have some question about managing solution,projects and codes for usability.
I want share this class library between projects and when i update it , the update applying easily to all projects.Where can i locate this class library to share between projects and improve source controlling , usability and ...?
Any Idea?
You can use NuGet packages as a means of distributing the DLLs - build your common assemblies, pack build results into a specific directory and use that directory as a repository for NuGet Package Manager. One part of NuGet options is downloading the latest package version automatically, so whenever you open the solution, the package manager scans the repository for newer version and downloads it, if there is one.
Here's a very easy tutorial: http://juristr.com/blog/2012/04/using-nuget-to-distribute-our-company/
You can use several approaches:
You can add this project as existing project to all solutions from one place. It is simplest method, but when it is changed in one solution, all other can become broken.
You can branch your common library project to all solutions as different brunch. In this case, when you change it in one solution, all other solutions will not brake, but you should spend much time to merge changes from all brunches of your common library.
A solution can contain many projects, so you can effectively put the class library project anywhere and reference it from each new solution as required. This means you have only one copy of the source on your machine.
When you build each project it will compile the class library if necessary so all you need to do is have some process that keeps the source up to date.