7 replies to this topic

[bill.french]

Sorry if this is really dumb. Let's say I have a class in a .cs file that I want to use in multiple projects. Is there any easy way to do this so that if I fix a bug in the class while working in one project, all the other projects will get the latest version of the file? Hopefully I'm phrasing this in a way that makes sense!

[Joe Griffith]

Right click on your project in the solution explorer, select Add and then Existing Item. Browse to where ever you have created the class file. If you examine the Add button at the bottom of the dialog you will notice that it has a small down arrow that will allow you to add the file as a link. Items added as links can be edited in either location but there is really only one file so changes made in one place will automatically appear in the other. When you add a file this way it has a little shortcut arrow on the icon in the solution explorer.

[Chris Walker]

You can also compile your class into a class library (assembly) and then just import it as a reference in other projects... Chris

[Mark H]

If you're going to add the class into a library, you might want to have a "libs" folder somewhere - this way you can just update the one assembly and each project that references it can pull that in. For example, as a development folder structure: D:\Projects\ - root folder D:\Projects\src\ - Visual Studio solutions D:\Projects\lib\ - Libraries that you don't want in the GAC D:\Projects\pcb\ - hardware projects

[bill.french]

Cool. This may have changed my life forever!

[Illishar]

If you're serious about it, you might want to place the referenced class under version control. Eg. SVN. That way you have better control over *when* to update the reference. (And *when* you just want the crap to work, without resolving 6 months of updates.)

[Chris Seto]

Yeah, if you get serious about software development, use a source rev software. Plus, It has the added advantage on my end of keeping all my work automatically backed up since my SVN server syncs to my NAS.

[Corey Kosak]

I'd wholeheartedly agree on the concept of version control. Once you get used to it, it alters your life forever. For example, I keep every single file I care about, not just code, under version control, and synced to offsite repositories.

However, I do think git is a better product than subversion.

But it's not just about keeping history. Once you become agile with source control, it's kind of cool what you can do. For a real-life example, in my interop project, I found myself doing this on one of the interop C++ files.

• Visual Studio made me a "stub" C++ file (call this version A)
• After committing it, I populated it with my code (call this B )
• (more changes, C, D, E)
• then I change my mind about the interface and I ask Visual Studio to start over and create a new stub file (call it F)
• Then I ask git to take my code changes (i.e. the delta from A to B, and likewise B to C etc) and apply them to F. This is super-easy to do in the gui.

This is just a simple example but hopefully gives you intuition about the power you have when you start thinking about your directory tree not as just your current bag of files, but rather as an entity which mutates over time (files change, and come, and go). Then you can think about revisiting a previous point in your history and manipulating, reordering, and selectively reapplying these "mutations".

When you get more advanced you can start thinking about "branches", which can be thought of as multiple coexisting parallel universes. In my example, I maintained a couple different competing versions of the firmware in different branches and switched between them (or moved changes between them) as I needed to. It's really a great lifestyle, once you get over the learning curve.