declaring nuget packages that depend on each other in one solution

后端 未结 3 1476
长发绾君心
长发绾君心 2021-02-07 11:50

We have solution with a lot of projects and a more or less complex dependency graph between those projects. Now each of those projects should become its own nuget package and th

3条回答
  •  栀梦
    栀梦 (楼主)
    2021-02-07 12:36

    The situation in our project is the same and we took the following approach:

    The first step is to create the nuspec files defining your packages. We have placed all theses files in a folder named ".nuspec" which is located in the solution's root directory. The nuspec files are added to the solution in a solution folder that is named ".nuspec", too.

    The solution itself has a global AssemblyInfo file that contains the versioning information as well as some copyright stuff - in short all information that is common between our projects. Each project then has its own assembly info adding the information specific to each project.

    The nuspec files do not contain a version. Instead we use $(version) as a placeholder there:

    
    
      
        MyCompany.MyProduct.Server.DataAccess
        $(Version)
        MyCompany
        http://example.com/myProduct.html
        http://example.com/myProduct.icon.png
        false
        Some description goes here.
        The summary goes here
        Copyright © MyCompany 2015
        en-US
        
          
          
        
      
      
        
      
    
    

    (Of course the dependencies might have dependencies themselves. The server component might reference a logging component for example.)

    Initially we created a console application reading the version of the solution from the global AssemblyInfo file and parsing it into all of the nuspec files before creating and publishing the packages.

    The console application worked well, but was a bit tedious to maintain in a TFS environment with continuous integration enabled. So we defined a custom TFS build template doing this work. All we need to do now to create a set of nuget packages for all of our projects is to trigger a TFS build.

    This approach has the advantage that all packages have the same version and thus work well together. This approach has the disadvantage that all packages have the same version and cannot be released independently.

    We chose that approach because it prevented us from producing a conglomerate of badly integrated components. Our projects provide a small framework that is used to develop small LOB-applications that all are quite similar. Due to the fact that we deliver the framework in a set of different packages the developers can choose which of the packages they actually need and then install only those. Should a developer decide to add a missing functionality lateron he just installs the relevant packages that have the same version as those already installed. Thus there's no need to worry about compatibility.

提交回复
热议问题