cadbloke / codelinker

Links code between Visual Studio Projects. Write once, build many

CAD bloke

aka Ewen Wallace

• https://www.CADtoNetbox.com automates CAD wiring drawings syncing with Netbox...

  • CAD to Netbox also includes my C# .NET Netbox API client generated from multiple versions of Netbox, not just from the YAML and not with SwaggerGen because that made an unholy mess. It is refined with info parsed from the Netbox source code.

• https://www.CableSchedules.com automates the boring bits of broadcast system design - cable schedules, offsheets, labels...

• https://www.CADreplace.com - AutoCAD and BricsCAD FIND but good. Replaces multiple things in multiple drawings in one step

• 📺 Broadcast Systems Design and Documentation since last century

• 💻 Developing: AutoCAD plugins & CAD apps since 2005, in C#, Lisp & VBA (yeahnah)

• past lives include 🎥, 📷, 🏎️+📹, 💻 in the 80s

on StackOverflow

https://www.linkedin.com/in/cadbloke

💬 Ask me about

• 📺 Broadcast systems
• 💻 software development
  • .NET C#
  • WPF
  • AutoCAD, BricsCAD, OpenDesign platforms
  • Lisp, VBA

🏡 home is

🐨 🐬 🐳 🍷 Newcastle, NSW, Australia

🍺 🍻 🍺

codelinker's Issues

Log File - um, where is it?

In the XML comment at the end of the clone, add the full path to the Log file so the user can find it.

or not because this will change per user. Perhaps add a note to direct the user to the log file.

... or put the log file somewhere disposable like the 1.vs` folder in the root of the solution.

Hrrrmmm, do the homework - where should the log file usually live?

If linked project is in the same folder as the original then you don't need links

• just include the code

Wiki: some bits make sense - fix the other bits

There are a few too many assumptions there. Also, use a proper example at https://github.com/CADbloke/CodeLinker/wiki/Illustrated-Example because that first picture is confusing

use timestamp to see if source needs parsing

Save a last-update timestamp for the source file in the target XML placeholder. If the source hasn't been updated, don't bother parsing it unless forced to.

Yay, another optional parameter. 👎

Code formatting looks like I was drunk the whole time

GUI app Ignores destination project Exclude settings

the GUI app just overwrites the destination project without reading the exclusions list from it first

GUI changes all things to lower-case - CMD version keeps case ok

Creating a linked project with the GUI makes all the file paths and link paths lower case. Running the commandline version to update the project restore the original case.

may actually be a problem with the "new" parameter

Nuget references - keep or delete?

<Reference Include="EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <HintPath>..\packages\EntityFramework.6.1.3\lib\net45\EntityFramework.dll</HintPath>
      <Private>True</Private>
    </Reference>

These are build platform dependent. I guess the project is cloned with with the <TargetFrameworkVersion> intact so the process of breaking the Nugets that is no different to changing the <TargetFrameworkVersion> in the Source project.

Write errors to the output window. Alert the user in an obvious way

tell the user when it broke.

GUI: Create the Destination folder if it doesn't exist

so I can just type in the destination path.

Magic happens, please.

option: create a subfolder for each new Destination Project

A lot of destination projects in the same folder will get messy very quickly if/when they gather their own local files like \Properties\AssemblyInfo.cs and local files they overrule from the Source etc.

Avoid Duplicates

If a file name exists in the destination project in the same folder then don't add it as a link.

Don't forget to check the <Link> attributes too.

Ignore projects not set up for Linking

Should not write anything to a project when it is meant to be updating and the target project has not been set up for linking

<None Include= seems to miss the relative folder path

<Compile Include= works ok
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> is preserved

non-GUI: In log file - report exclusion line number in csproj file.

Excluded: app.config
from: C:\Codez\CadBloke\GitHub\CodeLinker\codelinkergui\codelinkergui.csproj
because you said to Exclude: app.config

Where did I say that?

Doesn't handle wildcard Includes

<Compile Include="**\*.cs" Exclude="AssemblyInfo.cs;**\Temp*.cs" /> in the source csproj will crash the GUI when linking / re-linking.

Here's the crash

I crashed at Recycling. GetFullPath: C:\Codez\CadBloke\GitHub\CADtest\CADtest-CS\**\*.cs. Whups. See CodeLinkerLog.txt for details.
System.ArgumentException: Illegal characters in path.
at System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)
at System.Security.Permissions.FileIOPermission.QuickDemand(FileIOPermissionAccess access, String fullPath, Boolean checkForDuplicates, Boolean needFullPath)
at System.IO.Path.GetFullPath(String path)
at CodeLinker.DestinationProjLinker.LinkCode() in C:\Codez\CadBloke\GitHub\CodeLinker\codelinker\DestinationProjLinker.cs:line 158

Investigate a better way that doesn't need to reparse relative links (including wildcards) by tweaking the relative path of the Source Include to create the new Include for the destination project. Concatenating **\*.cs to the end of a folder paths should still work for Visual Studio / MSBuild but it's not a legal path name, hence the crash.

Test for

• linking a csproj that has already been linked
• linking a csproj into the same directory
• linking a csproj that has already been linked but now has a different, &/or shallower relative path than its source (that source being the destination of another source). ie. the new relative path for the Include is not just an easy string.Replace()...OR IS IT?

Nuget packages - they break

 <ItemGroup>
    <None Include="..\cadblokefindreplacenunittests\packages.config">
      <Link>packages.config</Link>
    </None>

Have a good look at the packages.config

• should there be a local copy? PERHAPS
• Will changing a canonical packages.config break it for all but one project? YES

Perhaps strip out all Nuget <Reference>s so the user can start from scratch after they set upstream build configs (framework etc)

or ... an option to copy and keep the Nuget packages.config file and the user can deal with it. NO because there are upstream things that need doing to make Nuget work

After creating projects - set up automatic linking post-build process

Make this optional

1. Copy the command-line CodeLinker.exe into a (user definable path from Solution or project root) Tools folder
2. Update the source csproj files with post-build instructions
   • don't forget to check the csproj file first

Is it better to copy some files rather than link them?

app.config & AssemblyInfo.cs are a couple of candidates. See also #9 for packages.config which is a really obvious candidate.

GUI: After linking the codez Tell the user if it went ok or not.

All the destination project names go red. Looks like it broke when it actually worked.