Sharing a constant betwen an EXE and a DLL in .NET



  • Do I really have to re-type (and maintain) the declaration in one file per project? In C++ I would just make a header file and include it in both codebases... in .NET there are no headers, and there's basically no "including." (I can't use "Add as Link" because it doesn't work with integrated source control.) 

    How are the rest of you dealing with this? Surely there must be some way to do this in .NET. I really like .NET but this concerns me!


  • ♿ (Parody)

    Lots of ways to skin this cat. First and foremost, there is no equiv of global variables in .NET; you can have a static class or enum to store constants. With that in mind...

    • "Add as Link" works pretty well to share files between projects; the strategy is to have the common files in a "Solution Folder" (in the IDE), and have a folder that maps to on disk so you can check-in/check-out files to; then, just "Add as Link" the common file with your constants
    • Create a DLL project ("Common") that contains common (public) code that both project referneces
    • Add a reference to the DLL in the EXE, and make it's contsants public


  • @Alex Papadimoulis said:

    Lots of ways to skin this cat. First and foremost, there is no equiv of global variables in .NET; you can have a static class or enum to store constants. With that in mind...

    • "Add as Link" works pretty well to share files between projects; the strategy is to have the common files in a "Solution Folder" (in the IDE), and have a folder that maps to on disk so you can check-in/check-out files to; then, just "Add as Link" the common file with your constants
    • Create a DLL project ("Common") that contains common (public) code that both project referneces
    • Add a reference to the DLL in the EXE, and make it's contsants public
     

    Thanks, these are some of the approaches I've been considering. "Add as Link" would be perfect - it's not that different from #include in C++ - except that it doesn't work well with source control. In particular, adding a project to source control using Visual Studio seems to silently convert the "link" to a parallel copy of the file... grrrr! Maybe this will be fixed after version 2008.

    Having a shared DLL is probably a good - albeit heavy - solution. Bloat aside, there are probably some security advantages to this approach compared to #including a header file in C++. Ultimately I would like to have both options.

     



  • Add Existing Item, in the select file dialog, choose the dropdown on the Add button and choose Add as Link, we use this method to include common assemblyinfo information for our product (20 projects, one solution, in TFS)



  • You could also put your "Constant" in the .exe's configuration file and read it in both the EXE and the DLL. (The dll runs in the same process as the EXE and thus inherits it's configuration file.)



  • @RaspenJho said:

    You could also put your "Constant" in the .exe's configuration file and read it in both the EXE and the DLL. (The dll runs in the same process as the EXE and thus inherits it's configuration file.)

    I like this approach best. It's slower and more complex than the C/C++ equivalent, but reasonably efficient and general for a .NET app.

    @XIU said:

    Add Existing Item, in the select file dialog, choose the dropdown on the Add button and choose Add as Link, we use this method to include common assemblyinfo information for our product (20 projects, one solution, in TFS)

    The problem (and it's a huge one in my opinion) is that if I add the project to source control using a provider that's integrated into the IDE, then the link is silently converted to a parallel copy of the file. At least, this is the case when using Visual SourceSafe, as of version 2008 of Visual Studio.



  • @bridget99 said:

    @RaspenJho said:
    You could also put your "Constant" in the .exe's configuration file and read it in both the EXE and the DLL. (The dll runs in the same process as the EXE and thus inherits it's configuration file.)

    I like this approach best. It's slower and more complex than the C/C++ equivalent, but reasonably efficient and general for a .NET app.

    @XIU said:

    Add Existing Item, in the select file dialog, choose the dropdown on the Add button and choose Add as Link, we use this method to include common assemblyinfo information for our product (20 projects, one solution, in TFS)

    The problem (and it's a huge one in my opinion) is that if I add the project to source control using a provider that's integrated into the IDE, then the link is silently converted to a parallel copy of the file. At least, this is the case when using Visual SourceSafe, as of version 2008 of Visual Studio.

    The RealWTF is Visual SourceSafe :) TFS and VS2008 just use a link in the .csproj file.



  • @XIU said:

    TFS and VS2008 just use a link in the .csproj file.

    TFS is basically the replacement for SourceSafe, right? Are you sure this actually works? Even after adding the project to source control from the VS2008 IDE??

    Microsoft fixed one of my pet bugs?!?



  • Absolutely sure, we have a our solution in TFS, VersionInfo.cs in the solution folder (which has the shared AssemblyInfo.cs code for our projects), each project has the VersionInfo as a link, so we can update version number in one place. Works perfectly.



  • I might be missing something (I hardly use vss so I may be wrong) but couldn't you just go into vss once pin te file to the project and forget about it?
    Pretty sure that once it's pinned in vss vs2005/2008 will know what's going on and treat it as a linked file instead of duplicating it...

    That said... I. A few months tfs 2010 will be available with tfs basic bridging the gap between full fat tfs and vss so it might be worth a look...



  • @wonkoTheSane said:

    I might be missing something (I hardly use vss so I may be wrong) but couldn't you just go into vss once pin te file to the project and forget about it? Pretty sure that once it's pinned in vss vs2005/2008 will know what's going on and treat it as a linked file instead of duplicating it... That said... I. A few months tfs 2010 will be available with tfs basic bridging the gap between full fat tfs and vss so it might be worth a look...

    I don't know about that. I've never 'pinned a file to a project' in VSS. The problem I had was that, when adding a project with links to VSS for the first time, Visual Studio silently converted the link to a copy before adding anything. At that point, there's no project in VSS yet, so I doubt there's anything I could do inside of VSS to address my problem.

     I suspect there are ways to clean up the problem after-the-fact; if nothing else, I could check out the .Csproj file and restore the link in Notepad. None of this really seems adequate to me; the simple basics ought not to require so much cleverness.


Log in to reply