1

I'm currently working on an ERP Blazor WebAssembly app that works alongside its base Razor Class libraries. The app could have some custom pages that aren't the same for all the customers and are independent (that means that the core app remains the same while the custom pages could get modified).

I've tried putting a git repo inside of the main repository using the git submodule but I'm not sure this it's the right approach.

I've also tried creating a different solution that holds all the different customer projects, compiling the only one I need and substituting the .dll file but it results in an integrity error.

Am I doing this correct? Can someone give me some tips/hints on the solution?

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
ImZac
  • 21
  • 3
  • According to your description, there is just one app and one library? Or do you have different variants of your app per customer? – Doc Brown Feb 06 '23 at 13:19
  • I have the main app that it's a Blazor WASM app, one base library with some shared components and a library that has different pages per customer. – ImZac Feb 06 '23 at 13:35
  • Then what is the issue with keeping the app and all libraries in one solution in the same Git repo? – Doc Brown Feb 06 '23 at 14:10
  • Should I keep different branches and then merge the app changes now and then? Also, isn't this approach difficult to manage when having more than 5/10 customers? – ImZac Feb 06 '23 at 14:18
  • If you would go the (wrong!) route of doing the customization by branches, that might become hard to manage. Instead, build one product with inbuilt customization. See also [this SE post](https://softwareengineering.stackexchange.com/questions/60393/how-to-maintain-different-customized-versions-of-the-same-software-for-multiple), but ignore the accepted and heavily downvoted answer, look at the ones with the most upvotes. – Doc Brown Feb 06 '23 at 14:32
  • Thanks! As for now I'm trying the one solution with different projects for every customer but I'm having troubles with publishing cause integrity is a thing. – ImZac Feb 06 '23 at 14:51
  • You did not tell us yet how you are doing your deployments, specificially deployments for individual customers. If you don't deploy individual source code to each of your customers, I would recommend you try the [approach scetched here](https://softwareengineering.stackexchange.com/a/60525). – Doc Brown Feb 06 '23 at 14:57
  • For each individual customer we publish our site to an internal testing IIS and the results inside of the target folder is what we filter and then deliver to them. – ImZac Feb 06 '23 at 15:03
  • But how do you differentiate technically between the different customers? Do you have one script per customer which compiles the release build and puts the required files on the "testing IIS"? That would be a good start. BTW, you should edit the question and describe your current customization and deployment approach, this is important information for answering and should not be hidden here down in the comments. – Doc Brown Feb 06 '23 at 15:16
  • Since the app is fairly new we currently have only one customer using it. We are starting to deliver it to others so I'd like to do this carefully and methodically. The initial idea was to use a script that compiles the library and and copies the dll to the target folder. – ImZac Feb 06 '23 at 15:23
  • I would recommend to have a script which compiles your whole application system (ideally just one SLN file), with all libs for all customers, and then copies the libs required for each individual customer into different folders. You can also do this on a CI server, if you use one. – Doc Brown Feb 06 '23 at 15:30
  • Thanks! I'll note everything :D – ImZac Feb 06 '23 at 15:39

1 Answers1

1

Based on our discussion in the comments, here is a summary of my recommendations:

  • In your current situation, it is most probably the most efficient approach to stay with one "solution" (sln file) containing all projects, the common libs, the customer specific libs and what else belongs to this application system, and just one repository.

  • Whenever you prepare a deployment of a new release, compile everything and copy the created files to customer specific folders. Don't do this manually, instead, create a script which does that for you. Or use a CI server, and make the copying of the files a custom build step after successful compilation.

That will save you from your integrity issues, and let you manage the whole application system as one product with inbuilt customization.

Of course, when your application grows and you will run into the situation where you have one team for your common "core framework", and other teams for individual customers, then it may be time for separating the life cycle of the core from the life cycle of the specific apps. Currently I think this isn't worth the hassle.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565