I decided to share a small project I have been working on for a while. It's basically a development framework for distributed applications.
Now I'm setting up the GitHub repository and I wanted to use AppVeyor for continuous integration and I'm struggling with the setup.
As for now, my framework is composed of few packages
Interfaces: defines the basic interfaces, extracted as a package so that you don't need to bring the whole framework in your business logic library
Core: contains the basic components of the framework
CastleWindsor: contains support for the Castle IoC container
RabbitMQ: contains the implementation of the engine based on RabbitMQ
Now, it's pretty easy to setup AppVeyor to build and push into Nuget a single project/package.
But what I'm looking is:
build everything on push (includes testing)
create packages and publish them only on a specific action.
I'm wondering if I should create multiple repositories (one for each package) on GitHub and have multiple projects on AppVeyor as well. Or maybe a single repository with multiple projects.
Thanks for your insights.
Related
We are currently in the process of migrating from IBM ClearCase as centralized Version Control to Git / Azure DevOps. It is a large and long grown software project in C# with more than 100 C# projects distributed over about a dozen solutions with some dependencies inbetween, at the moment via Project References.
So far all those solutions were managed with ClearCase in a common folder, however for Git it seems to be best practise to use one solution per repo and handle dependencies cross repo with NuGet Packages.
I wanted to ask for experiences in migrating and splitting such projects, did you come across situations where it was better to include multiple C# solutions in a repo?
How do you manage multiple repositories that belong to one software with one release cycle? We plan on using release branches and I think we have to write a script that branches all repositories belonging to the project or is there a more convenient way, maybe provided by Azure DevOps?
I have written before on ClearCase migration to Git.
In all instances, the scenario was the same:
don't import the full history, only major labels or UCM baselines
split VObs per project, each project being one Git repository
revisit what was versioned in Vobs: some large files/binaries might need to be .gitignore'd in the new Git repository.
You can still reference all your Git repository (C# projects) in one parent Git repository, through Git submodules.
You can also go the monorepo route: after all, that is what Microsoft is doing with its "The largest Git repo on the planet".
But in that case, you might need to use Scalar, and sparse checkouts.
See:
"Bring your monorepo down to size with sparse-checkout"
"Make your monorepo feel small with Git’s sparse index"
Im developing 3 Azure Functions called EmployeeAPI, StudentAPI, ProjectsAPI all of which is accessing the same SQL database. I was instructed to make sure that each of projects are deployed separately independent of each other (separate code repository for each).
My problem is there are some common projects that are shared between the 3 and its a pain maintaining all 3 of them. If I changed 1 item let's say a database column, I need to update it on other projects as well.
Is there a way that the common project will reside in 1 repository and the changes will reflect on the 3 projects? Some advised me to create a Nuget package or reference the project.
This is the solution structure of each project (simplified)
EmployeeAPI
ApplicationLayer (shared)
DomainLayer (shared)
InfraLayer (shared)
Tests (shared)
StudentAPI
ApplicationLayer (shared)
DomainLayer (shared)
InfraLayer (shared)
Tests (shared)
ProjectsAPI
ApplicationLayer (shared)
DomainLayer (shared)
InfraLayer (shared)
Tests (shared)
I hope I explained it well :-D
Actually moving shared project to nuget package is the best what you can do if you want to keep API projects in separate repositories. Here you have docs showing you how to push nuget packages to feed.
You can also move all your shared project to 4th repo and the use them as submodule on your API projects. Here you have details about using submodules in Azure DevOps.
Assuming you are using Azure DevOps for CI/CD then you can use path filters like here to include/exclude and have all the functions and shared projects in one repository. Maybe you can achieve similar functionality using other CI/CD tools.
I have designed a selenium framework taking the concept of POM(Page Object Model). I want to create a generic file of that framework keeping the required dll's so that it can be used by the manual testers within the team to automate other applications.
You can package the framework aspect as a NuGet package. The package can then be ingested by the other projects that require it.
See: https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package for how to create NUGet packages.
See: https://learn.microsoft.com/en-us/nuget/quickstart/install-and-use-a-package-in-visual-studio for how to use NuGet packages.
Each test project can then include that NuGet package and implement it's own page object model classes for the specific application they are testing.
I would like to know how I can share c# source codes between two (or more) .NET Core projects (commandline projects!).
As far as I understand, I can not link to source files in different directories in xproj/project.json based projects. I noticed that it now seems to be recommended to create nuget packages for everything. But is it really necessary for me to setup a private repository and create a nuget package only to be able to share some common source units?
VS2015 contains a template for .NET Core library which may be suitable for building a shared lib. Is it possible to link this lib to a project without a nuget package?
.NET Core Library is an excellent solution for you.
Do it the same way as in standard C# solution - just create the project and reference this project or add a reference to DLL file.
You don't need to use a Nuget, for your own purpose. Nuget packages could be useful to distribute your dll outside.
Clarification:
I miss one point - I'm using VS2015, but I have included Class Library project in my solution, and I'm referencing by project, not by DLL file, and this works fine in ASP.Net Core.
I also have a different project, where referencing DLL file directly working fine, but this is the previous version of ASP.NET app (not Core) - seems NET Core doesn't support this way like as the previous version (yet?).
Sorry for confusing you, sometimes it's too many technologies ;)
So could you just include ClassLibrary project into solution with your project and refer it as a project?
I have achieved this by using source control to branch from my commonly used projects in each new solution, and again merging back to the master branch if I make any changes.
Alternatively, baring in mind that NuGet is only an archived collection of files, you could keep this NuGet package locally, or even create a Template for Visual Studio that has the common libraries by default.
There are a wide range of possibilities that are down to your preference, and current environment state (I.E: Able to setup Source Control, or a package repository).
This is much of an architectural level question where I am stuck at. I was planning to implement nuget onto our enterprise project to get rid of multiple levels of deployment/re-building of projects. Here is the Project structure:
Framework (class lib solution): It is referenced in every other solution
ParentClient(WPF App Solution): It is the host client, it can contain many other module inside it which are different solutions as (3). This also uses Framework dlls
MyClient(WPF solution): This client is a module which also uses Framework dlls
Now presently whenever there is a change in Framework's dlls, the corresponding other solutions/projects must be updated, since in the actual deployment environment(a windows machine/ Client Machine) all the dlls resides in the same bin folder. If I do not update the framework dlls, then the present module won't function, and if I do, it might impact the existing application which do not require the latest framework update although due to the latest changes, it somehow breaks the current functioning. (Remember: This issue is due to the fact that in the ParentClient, we have multiple modules say MyClient, YourClient etc)
I would like to know whether or not we can use Nuget or does Nuget will might help me in resolving the issue...???
Yes, NuGet is the way to go. You can set up a very simple NuGet Server by simply creating an empty MVC application and then getting the NuGet Server project template from... nuget :)
An even easier solution, is to simply host your NuGet packages from a network share. You can then keep all versions of your dll's there, and address them from your CI/Build server. Nuget supports adding a network share as a source, and this is common practice