1

Topic: Control of binary files of the project

Before rushing to create the next bicycle, decided to consult here Here never thought that it is necessary to suspect this subject... In the simplified type the problem looks so. 1. Is solution with two connected.NET projects: program1.dll |-> library1.dll At each unit the version (it is generated by the automatic machine a repository of initial texts). This couple is spread through a MSI-package and a NUGET-package. The packet version undertakes from program1. I do not subtilize also each time completely I will recompile all solution. Generators of packets (MSI, NUGET) take  directly from bin-catalogs of projects program1, library1. That is often there are cases when library1.dll did not exchange (and its version remained former), but I all the same spread its new file in packets. - - 2. Now in solution appears program2 which will be  both from program1 and from library1 program2.dll |-> program1.dll |---- |-> library1.dll And the problem with a NUGET-package was designated. Each unit needs to be packed now into own NUGET-package (with dependences). If the unit did not exchange - it is not necessary to create a NUGET-package. The Same with MSI. If library1 unit did not exchange, in new MSI it is necessary to include that library1 which was already published in previous MSI. - - I see such solution of a problem: 1. It is necessary to create a catalog tree with published : <published_binaries> | |--> <module_name1> | |---> <module1_version1> {here there will be files (DLL/EXE, PDB) for this version} | | | |---> <module1_version2> | 2. Generators of installers will work with the special directory <install_data>, instead of bin-catalogs of projects. 3. After the full recompilation solution, the formation script <install_data> on the basis of contents of directories <bin> and <published_binaries> is launched. If in published_binaries is  with the same version in install_data it will be placed, instead of it anew recompiled assembly. 4. Installers with not changed version (it is included in a name of its file) will need to be ignored. 5. After the publication of the installers, new  from <install_data> it is necessary to register in <published_binaries>. Earlier, it is impossible, because after creation of packets it to appear that all can is necessary anew . That is two are necessary  for point 3 and 5. Point 4 ( repeatedly created installers) too probably should be automated... Though if titles of files of packets unique it is not difficult. - - all Turns out difficult and turbidly. And I, most likely, some moments did not catch up with it. How all it to avoid?

2

Re: Control of binary files of the project

Hello, Kovalenko Dmitry, you wrote: > As all it to avoid? You and did not tell what task try to solve.... <<RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

3

Re: Control of binary files of the project

Hello, AndrewVK, you wrote: AVK> Hello, Kovalenko Dmitry, you wrote: >> As all it to avoid? AVK> you and did not tell what task try to solve. Yes, the task is a little chaotically described. Though I tried 1. I do not subtilize also each time completely I will recompile all solution. Generators of packets (MSI, NUGET) take  directly from bin-catalogs of projects program1, library1. That is often there are cases when library1.dll did not exchange (and its version remained former), but I all the same spread its new file in packets. 2. The same with MSI. If library1 unit did not exchange, in new MSI it is necessary to include that library1 which was already published in previous MSI. It is necessary to automate process of detection of assembly which did not change the version and to include in distribution kits their earlier published copies. For this purpose it is necessary to construct the directory (storage) of all  and to write under it control code. - - As a whole I already almost mastered this task. The storage structure looks so: lcpi.data.oledb.net4.debug.dll | +--- {MSIL} {ff716095e8002e7e} {1.3.0.2965} {} {a. net Framework 4 Client Profile} | lcpi.data.oledb.net4.debug.dll | lcpi.data.oledb.net4.debug.pdb | lcpi.data.oledb.net4.debug.resources.dll | +--- {MSIL} {ff716095e8002e7e} {1.3.0.2965} {ru} {} | lcpi.data.oledb.net4.debug.resources.dll | lcpi.lib.net4.debug.dll | +--- {MSIL} {ff716095e8002e7e} {1.0.0.1276} {} {a. net Framework 4 Client Profile} | lcpi.lib.net4.debug.dll | lcpi.lib.net4.debug.pdb | lcpi.lib.net4.debug.resources.dll +--- {MSIL} {ff716095e8002e7e} {1.0.0.1276} {ru} {} one utility lcpi.lib.net4.debug.resources.dll is For this purpose written. 1. On an input on it palm off: A. A folder with anew recompiled  B. A folder with storage before generated . 2. On an output it forms: A. A folder, similar 1A but in which  with not changed version are substituted on old assembly (from storage) with the same version. B. A folder with new elements for storage of assembly. Generators of installers (MSI, NUGET) work with a folder 2A After the publication of installers, it is necessary to copy 2B in 1B.

4

Re: Control of binary files of the project

> If library1 unit did not exchange, in new MSI it is necessary to include that library1 to make three parts instead of two, I think that there should be smaller parts - such as msm https://msdn.microsoft.com/en-us/library/aa243932 (v=vs.60).aspx which then to pack in two msi

5

Re: Control of binary files of the project

Hello, Ejnstok Fajr, you wrote:>> If library1 unit did not exchange, in new MSI it is necessary to include that library1 > to make three parts instead of two, I think that there should be smaller parts - such as msm > https://msdn.microsoft.com/en-us/library/aa243932 (v=vs.60).aspx > which then to pack in two msi the Task consists that after the full recompilation of a product (consisting of several units) to reveal units which did not exchange and to include in MSI their earlier collected . Product units also are delivered separately through NUGET-packages. That is I at first spread a product v1.0: MSI: program1.dll (v1.0), library1.dll (v1.0) NUGET: library1.dll (v1.0) NUGET: program1.dll (v1.0) the product v1.1 refers to a nuget-package with library1.dll (v1.0) After a while: MSI: program1.dll (v1.1), library1.dll (v1.0 -  from the previous release) NUGET: program1.dll (v1.1) refers to already published nuget-package with library1.dll (v1.0) At the full compilation of a product v1.1 anew it will be generated  library1.dll (v1.0). It is necessary to reveal and replace it on  from a product v1.0. It is possible certainly to solution a product to connect ready  library1.dll. But it complicates development process.