2

I'm using Visual Studio 2010 to amend a C# project.

Part of the application requires the user to be able to save and read a settings file (1 Project reads them in (as read only) from a file. The other project reads them in from the file to be shown in the GUI and when saved, the file is to be overwritten).

If both of these files were in 1 project, I could share it easily (using Resources.resx for example or any other approach). The issue I have is the project that reads the settings file is different to the project that writes/amends the settings file.

The 2 projects are not allowed to be referenced to each other (they apparently have to remain oblivious to each other existence) so I can't share a CONST STRING between them.

Now, I may be taking the DRY principal too far, but I am worried about writing code reference the a single file in multiple projects (next OS change may break this logic etc).

I'm going to assume that this decision isn't uncommon and that an approach(es) already exist to overcome this issue?

Is it just a question of having the same file referenced in 2 locations (and if that file changes, having to update each reference (this seems undesired)) or is there a better way?

Improve this question
8
  • save and read default settings Do you mean "change default settings in order to apply overridden user settings"?
    – Davin Tryon
    Commented Dec 20, 2013 at 11:41
  • Yes, correct. 1 Project reads them in (as read only) from a file. The other reads them in from the file, allows them to be updated and therefore the file to be overwritten.
    – Dave
    Commented Dec 20, 2013 at 11:42
  • Otherwise, what you are describing is a situation where a contract needs to be defined that allows the "reader" to gain access to a file that the "writer" owns.
    – Davin Tryon
    Commented Dec 20, 2013 at 11:49
  • @DavinTryon, your comment contract needs to be defined that allows the "reader" to gain access to a file that the "writer" owns. describes this situation perfectly!
    – Dave
    Commented Dec 20, 2013 at 11:51
  • 1
    Instead of hardcoding the file location in both applications, you could set it in both applications' .config files. This way you won't need to rebuild, repackage, and redeploy either application in the event the path (or OS as you mentioned) changes.
    – MetaFight
    Commented Dec 20, 2013 at 13:43

1 Answer 1

Reset to default
2

You've a couple of options.

  1. Create a third project that contains the shared functionality. Both existing projects reference this new DLL, problem solved.
  2. Put the functionality that you'd put in a shared DLL in a .cs file in one of the projects. Then add the file to the second project, but hit the drop down on the "Add" button on the "Add existing item" dialog, and choose "Add as link". The file only exists in one place, but appears in both projects as if it existed in both projects.

Hope this helps

Improve this answer
3
  • I did think of the first option but I had totally forgotten about adding as a link. I've been exposed to this before but I have no idea what it actually does (other than the obvious) so I will go away and research links now! This is a great answer.
    – Dave
    Commented Dec 20, 2013 at 12:10
  • 2
    Personally I'd go with the first option, it very plainly shows that the projects have dependencies. The linked file is easily missed, and forgotten about.
    – Binary Worrier
    Commented Dec 20, 2013 at 12:18
  • 1
    Would option 2 not violate "they apparently have to remain oblivious to each other existence"? Although there is no project reference via a DLL, there is the file link.
    – user59983
    Commented Dec 20, 2013 at 12:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.