Let's say I have a c# project Foo and a classlibrary called Bar

I'm wanting to develop Bar alongside Foo which will use Bar as a shared library. I'd like to keep these Foo and Bar in their own git repositories.

When I debug Foo, I'd like to be able to step into Bar to see what it's doing under the hood. When I make changes to Bar, I'd like to be able to have my changes reflected in Foo. It's okay if I'd have to build Bar first for my changes to take effect.

When I eventually deploy Foo, I'd like to import Bar as a nuget package, rather than including it as a part of the solution for Foo

Is this possible in c#? I've been trying to develop a shared library and a repository that uses that library as a template for future projects. I've tried to publish Bar as a nuget package to my local filesystem but it's been giving me problems; I'm unable to step into functions that call into Bar from project Foo and when I make changes to Bar I have to build, pack, then publish the library again. If I don't bump the version number of bar when I do this, this results in errors where I have to go to the nuget package in my filesystem and delete it manually.

Aside

If you're interested Bar contains extension methods for setting up a connection to a message broker along with classes for configuration definition and "contract" classes that need to be shared among projects.

CodePudding user response：

you can go red path or blue.

"Is this possible in c#?" - This is not c# or any language. This is solution/project management. Many things are possible. You can definitely develop as raw projects or DLL. Include debug-built DLL and PDB file into your nuget, and you will be able to step through your referenced library.

You don't have to use a separate solution from yout GIT/TFS. You can develop using any local solution, not binded to source control.

CodePudding user response：

I'm wanting to develop Bar alongside Foo which will use Bar as a shared library. I'd like to keep these Foo and Bar in their own git repositories.

Yes. In Foo, add all files from Bar as needed by add as Link. Namespaces and files will be honored as if they existed in Foo; but no files will be copied...only referenced.

This is an old Silverlight trick to share one set of code between two projects because of the two different versions of the CLR from the web services to the Silverlight project. It allowed models to be brought over from the web services without trying to pull in a dll which had a totally different CLR.

Create the code in project 1. Then for project 2, add the files by linking them from project 1. To do that type of add, its really adding a symbolic link to the file(s).

How

The trick is to include as a link into the project as needed.

1. In the second project right click and select Add then Existing Item... or shift alt A.
2. Browse to the location of the file(s) found in the first project and select the file(s).
3. Once the file(s) have been selected, then on the Add button select the drop down arrow.
4. Select Add as link to add the common files(s) as a link into the project.

I'm unable to step into functions that call into Bar from project Foo and when I make changes to Bar I have to build, pack, then publish the library again.

The linking of files, as mentioned, will gain access to the file as if the file was actually within the project, but the file physically resides elsewhere. If the linked file(s) change, those changes are reflected in the project that linked them in. Building due to changes still applies, but that should be minor.