TheSwamp

Code Red => .NET => Topic started by: Jeff H on August 17, 2015, 12:26:05 AM

Title: Visual Studio Shared Projects
Post by: Jeff H on August 17, 2015, 12:26:05 AM

Anyone using shared projects(It is like adding all files in project "As a link" when referenced into project)

From first link below here is a snippet

Quote

Shared Projects let you write common code that is referenced by a number of different application projects. The code is compiled as part of each referencing project and can include compiler directives to help incorporate platform-specific functionality into the shared code base.

Shared projects were added to Visual Studio 2013 update 2 for universal windows project and later a extension to use shared project for any project type, but 2015 has built in template.

Here are some links
Cross Platform Code Sharing – Part 2 – Shared Projects (https://codemilltech.com/cross-platform-code-sharing-part-2-shared-projects/)
Shared Project : An Impressive Feature of Visual Studio 2015 Preview (http://www.c-sharpcorner.com/UploadFile/7ca517/shared-project-an-impressive-features-of-visual-studio-201/)
Using Shared Project across multiple applications in Visual Studio 2015  (http://dailydotnettips.com/2015/07/28/using-shared-project-across-multiple-applications-in-visual-studio-2015/)


Some threads where similar topics were discussed here at Swamp
Migrating From AutoCAD 2012 to 2013 (http://www.theswamp.org/index.php?topic=41850.msg469855)
Targeting Multiple AutoCAD Product Releases: Source Code Portability (http://www.theswamp.org/index.php?topic=41868.msg497358)
 

Title: Re: Visual Studio Shared Projects
Post by: CADbloke on August 23, 2015, 07:07:06 PM

Not yet  but I plan to look into it when I get back from my ONE WEEK HOLIDAY...sorry, was I shouting? ;)
 
Presently I manually edit csproj files like thus...

Code - XML: [Select]

1. <Compile Include="..\Path\To\ParentFolder\*.*"
2.         Exclude="..\Path\To\ParentFolder\NotThisOne.cs;..\Path\To\ParentFolder\NotThisOneEither.cs">
3.   <Link>ParentFolder\%(RecursiveDir)%(Filename)%(Extension)</Link>
4.  </Compile>
5. <!-- Visual Studio loves to refactor these things so I always add it as a comment too so I can restore it.
6.        Source Code repo check-ins are an easy way to spot this when it happens.
7. <Compile Include="..\Path\To\ParentFolder\*.*"
8.         Exclude="..\Path\To\ParentFolder\NotThisOne.cs;..\Path\To\ParentFolder\NotThisOneEither.cs">
9.  <Link>ParentFolder\%(RecursiveDir)%(Filename)%(Extension)</Link>
10. </Compile>
11. -->
12. <!-- This sort of abomination is also possible, if not advisable -->
13. <Compile Include="..\zSourceCode\**\*.*"       Exclude="..\zSourceCode\Properties\AssemblyInfo.cs;..\zSourceCode\bin\**\*.*;..\zSourceCode\obj\**\*.*;..\zSourceCode\**\*.csproj;..\zSourceCode\**\*.user;..\zSourceCode\**\*.vstemplate;..\zSourceCode\readme.txt;..\zSourceCode\**\*.lsp;..\zSourceCode\**\*.scr;..\zSourceCode\**\*.ico;..\zSourceCode\**\*.txt">
14.  
15. <!-- This has an absolute path with a  variable previously declared in this or another .csproj file -->
16. <Compile Include="$CadExtensionClassesRootFolder$\Common\*.*" >
17.   <Link>Common\%(RecursiveDir)%(Filename)%(Extension)</Link>
18. </Compile>

Upsides

• the files show up in the project you're working on as linked files
• portable if the paths are relative within the same source control repo
• works in Visual Studio version everything

Downsides...there are many...

• Adding a file to the wrong project is too easy
• You need to reload the project with the linkage in it to refresh the view.
• Often when you edit a file the Solution Explorer highlights it in a project you weren't expecting
• Hand-editing .csproj files gets boring pretty quickly
• Housekeeping is generally a bit of a nightmare
• Visual Studio loves to obliterate these wildcard expressions and replace them with a specific list of files, I usually add the same XML as a comment so I can re-edit the csproj file (hence the example above)
• Did I mention hand-editing .csproj files gets boring pretty quickly?

For those wondering "Why Bother???"
... shared projects / my hack above is a great way to have one lot of source code to maintain for different projects for...

• Core Console vs AutoCAD
• Different versions of AutoCAD
• RealDwg
• OEM
• BricsCAD, NanoCAD, IntelliCAD, ARES etc projects
• Library code for all your  things - that path in the example is relative but it can be an absolute path and can contain Environment Variables so if you are consistent about where you put your code on different computers than this can work well. I use %Codez% & %Dropbox% Environment variable everywhere.

... if you're copy-pasting source code around projects to build all these different things then you have a bigger housekeeping headache than just a few csproj files. Tip: Conditional compilation symbols and #if ... #endif are your friends in the monolith source code repo. As bothersome as the housekeeping on this has been, I have found this much easier to maintain than duplicate source code.

...the more I think about this the more I think this would work better as an imported project that has no project references, build configs etc. but housekeeping would still be tricky and it would still involve manual editing of .csproj files.

Title: Re: Visual Studio Shared Projects
Post by: CADbloke on August 23, 2015, 07:15:41 PM

From Jeff's first link https://codemilltech.com/cross-platform-code-sharing-part-2-shared-projects/

Highlighting is mine. Note the refactoring issue is also a problem the the hacky .csproj editing method I outlined above. Third-party libraries (like, say, AutoCAD) are a-ok in the hack.

Quote

Disadvantages
While a Shared Project does have full access to the .NET framework, you cannot add any references to the Shared Project itself.  That means any 3rd party libraries, even libraries that you’ve created elsewhere, are not available.
Another is no separate DLL is created – all of the Shared Project’s code is compiled to be a part of the referencing application’s binary itself.  Any assets, such as images or other media are compiled into the referencing binary as well.  So code sharing across different solutions is not possible with the Shared Project.
Refactoring is difficult with a Shared Project.  Any code within a preprocessor directive that is not a part of the active project will not be touched during a refactor.  That can lead to a mess very easily.
All of the preprocessor directives themselves can also lead to a real mess in your code.

Title: Re: Visual Studio Shared Projects
Post by: CADbloke on September 06, 2015, 07:42:31 AM

I'm still investigating this. Here's another interesting experience from a good, very credible source: http://www.lhotka.net/weblog/PCLSharedProjectsAndNuGet.aspx

====== EDIT October 2, 2015 ====

I'm having another crack at this at https://github.com/CADbloke/CodeCloner

This time around I'm focusing on propagating source code to destination Projects which control all their own build settings. Apparently some (all) of us though that 72 builds in one project was a little unmanageable </YesItWas>.

There's an extensive readme there so I won't duplicate it here. I'd love to hear any thoughts, suggestions, WTFs.
My earlier works left here to serve as a warning for others..and also because there are a couple of useful tips in there.
...