I am using VS2019 Community Edition and have created a C# Console App solution in one instance of VS2019 and a C# Shared Project in another.
I have added a class to the Shared Project and then want to reference this shared project in the other project, so I right-click the References and choose to Add reference, then choose Shared Projects. The resulting window shows an empty list. Am I doing something wrong?
Other questions I have found suggest that the wrong Shared Project was created, i.e. using the wrong language, but I have checked and mine are indeed both C# projects.
The other suggested methods were to add it to the project manually by editing the .csproj file, which didn't work either, or something to do with MS Build config which is more than I want to get involved with.
Is it me or VS2019?
UPDATE 1:
So I managed to kind of fudge it, buy adding the Shared Project to the same project as the console project, but storing it in a different folder and reusing the .sln solution file to load it as a solution in VS2019. Progress, but even though I can add it as a reference, it doesn't seem to know about the classes in the Shared Project, even with a using reference.
Related
I just came across this scenario and thought I'd share it in case it saves you some time.
I have a fairly large solution in VS2017 and have a shared project that contains some common code such as enums.
I just tried to add my shared project to another project (right click project, add reference and go to shared Projects section) and noticed that the shared projects was empty. It wasn't giving me the shared project as an option.
See my answer below...
After a bit of digging it dawned on me that my shared project is C# whereas the project I was trying to add it to was VB.Net.
Obvious when you realise it, but I was still thinking of a shared project compiling to an assembly (dll) which could be referenced from VB.Net or C#. Whereas a shared project should be thought of more like a C++ include. Shared projects simply insert the source code into the recipient project and can only be used with projects of the same language.
I am working on migrating a windows application from Vs2008 to VS2013.I have a solution containing 5 projects(lets say P1,P2,P3,P4,P5). And I have another solution which contains only one project(lets say XYZ).All projects in first solution references the project in second solution. After adding XYZ project dll in reference folders of 1,P2....and when click(F12/"Go to definition") on any method of XYZ it redirects me to a class file in temp folder. I know that if we add reference through "projects" option then we wont get this error. But here XYZ project is in different solution and I am supposed to add dll by browsing it. Any solution for issue?
Note: framework versions of all the projects are same.
In my .net project I have 4 class libraries and a web project. Can you please guide me towards the correct way to add a reference of one class library to another class library?
In every project inside Bin there are two folders:
Debug
Release
I have tried selecting an assembly reference form Bin/Debug/, but every time I clear my project, all references are lost and I have to build projects one by one, which is a sort of pain. Also, it looks like when I build projects in Release mode these references will not work again.
My way of referring is probably not correct. Can you please guide me towards the best way to use references? Is there any way that I can be saved from these issues?
The bin and release folders are there for building the project, thus when cleaning the solution those will be deleted (usually).
We usually add a folder, and place referenced assemblies in this folder, the folder forms part of your main solution structure, so it may be checked into source control.
Please any one explain this. This Question helps to understand common things
Question:
What is the difference between when you 'add DLL reference from one project to another project via Browse Option and Add DLL reference from Solution project to another project and copy-paste from one project to another project'?
I have found an answer on google
Answer:
Adding a project reference adds a local project's DLL to the project that references it, and every time the solution compiles, the updated DLL for that project gets copied to the other project. So when you go through the build process, if you have 5 projects, each one rebuilds its DLL, and copies that DLL to its references.
But:
I don't know what the process is and the difference when we copy-paste from one project to another project?
When you do copy paste from One project to another, the dependent project add its reference of the file that you have paste in the project solution directory
When you do copy paste the dll of one project to the other project's directory and then Add its reference by browsing to that directory where you have pasted your dll. Then VS only add its reference and copy that dll to its bin folder and show you (allows you) all the method and properties that it contains.
If you do any change in your source project solution like adding or modifying methods then the updated dll of that project is not available in your dependent project solution.
So VS still points to the old dll file just because of the reference you added. So whenever you made any change in your source project solution, you have to add the reference of the updated dll to your dependent solution every time.
In Second Case: When you add reference of your source project into your dependent project solution, VS always take the most recent updated dll from your source project into your dependent project. So in this way you don't need to add reference every time you compile the code or debug.
When you just reference a DLL by browsing to it, VS would copy it to the output directory of the dependent project.
Suppose afterwards that DLL is updated - there is no guaranty that VS would retake that updated DLL, and copy it again to the output directory of the dependent project - which mean, that even after you fixed some bugs in the other project, those bug would persist in the dependent project (because it is still using the previous version of that DLL).
When you add reference to other project in the solution, VS would always take the most recent and updated DLL outputted from that project.
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.