3

I've done quite a bit of research into how I should manage my problem, but I just can't seem to get a grip on what I want to do. More importantly, I need to create a solution that the other members of my team will be able to follow relatively easily. The solutions I've tried work for a single developer, but would cause confusion between team members.

I currently have a branched structure like so:

  • ProjectName
    • Main
      • DemoProject
      • DemoEntityFramework
    • QA
      • DemoProject
      • DemoEntityFramework
    • Dev
      • DemoProject
      • DemoEntityFramework

I would like to pull the DemoEntityFramework out and Branch it in the same fashion, Main/QA/Dev. The reason I need it branched is because it's very common for the database structure to be different between branches. Thus, QA would not properly build when pointed to the PROD version of the EntityFramework. Another reason for pulling it out is because I have other projects that rely on the same framework and I could reuse the library instead of having to keep additional copies of the entity framework in those projects as well.

I've seen people suggest NuGet to handle the dependency. I'd be fine with that but I'd need a way to have each branch pull the respective dependency without breaking when I do a merge.

Cory
  • 1,794
  • 12
  • 21

3 Answers3

2

The best solution is use NuGet to handle the dependency in your case. You could define different package sources per branch in a NuGet Config File.

<packageSources>
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
    <add key="MyRepo - ES" value="http://MyRepo/ES/nuget" />
</packageSources>

You could create a different NuGet repository per branch, create a different NuGet configuration file for each branch and simply define the correct repository URL in that config file.

If you do not like use Nuget, you want to keep all dependent assemblies in a folder within the team project that is outside of the branch. To make sure relative references not break, you have to keep that all branches be at the same folder depth within the team project. No matter the assemblies folder branched or not, the relative references should be created properly. More details please refer this grate blog: Project Dependencies will break with branching if not done properly

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • 2
    Would I then not check in the NuGet config file? Or make sure it doesn't get merged? If the file gets merged, then it would again break the reference. I'll take a closer look at the link you provided, it looks promising but after a quick glance I don't see how I could get around the issue of the dependency being branched. My branched project is at the same depth, so I could easily reference the same DLL, but I can't easily reference a DLL that is in different folders. They're at the same depth, but a in separate folders: Dev/Main/QA – Cory Mar 22 '17 at 14:52
  • If only there was a variable of some sort that I could set to pull the branch name. I could insert that into the relative path and that would fix it. – Cory Mar 22 '17 at 14:54
  • @Cory You need to check in the NuGet config file and should be careful when merging/branching. You can refer this similar one: http://stackoverflow.com/questions/12864330/nuget-repository-per-branch-with-tfs This is the best way at present, unfortunately there is no perfect solution. After all you also did quite a bit of research. Besides we usually do not branch the assemblies folders. If my reply helped or give you a right direction, could you [mark it as an answer](https://meta.stackexchange.com/questions/5234/how-does-accepting-an-answer-work), which also help others in community. – PatrickLu-MSFT Mar 23 '17 at 14:40
  • Marking as the answer now. I wanted to give some time for other answers first. I've seen that post, and will likely have to resort to something similar. Thanks for the help. – Cory Mar 23 '17 at 18:48
  • I actually found another way to accomplish what I wanted. Thank you for your suggestion, but the way I've found seems to work best with minimal configuration. – Cory Mar 27 '17 at 20:43
0

I'm including this answer because it's a different approach than normal, yet it seems to fit my situation the best.

I really liked the NuGet approach once I implemented it, but I REALLY didn't like the idea of having a discrepancy between the NuGet configuration. It would be very easy for someone to accidentally merge that file between branches, as well as preventing the possibility of doing a merge on the entire branch.

I already have different Configurations defined in my project to do transforms for things like connection strings. I REALLY wished there was a way to do the same thing with project references. Turns out there is a way. Based on the configuration selected I can now have it point to different DLL paths. EVEN if they're not in the same hierarchy. Now, I simply point to the appropriate branch based on the Configuration.

Here's an example of what I changed in my .csproj

<ItemGroup Condition="'$(Configuration)' != 'Dev'">
  <Reference Include="MyReference, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
    <HintPath>C:\Example\Prod\MyReference.dll</HintPath>
    <Private>True</Private>
  </Reference>
</ItemGroup>
<ItemGroup Condition="'$(Configuration)' == 'Dev'">
  <Reference Include="MyReference, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
    <HintPath>C:\Example\Dev\MyReference.dll</HintPath>
    <Private>True</Private>
  </Reference>
</ItemGroup>
Community
  • 1
  • 1
Cory
  • 1,794
  • 12
  • 21
0

Some time has passed, and with time, so has our strategy. I've been looking into better programming 'standards' if you will and came across dependency injection. I've always know about it and have even mettled in it in the past. But I was only scratching the surface.

Our new approach works kind of how Patrick-MSFT was mentioning with Nuget. Except, now, I've combined each different EF project for the respective regions into a single solution and deploy to Nuget on each successful build.

Then, in my "DemoProject" I use dependency injection (constructor injection) to pass the appropriate EF context (wrapped in a repository) to the controller/class/etc.

Doing it this way I can now decouple my projects from needing to worry about the EF projects. This further helps with our source control and continuous deployment as well.

Cory
  • 1,794
  • 12
  • 21