ThinkGeo.com    |     Documentation    |     Premium Support

Daily Development Build Assembly changes

#1

   Every daily build you recompile all your assemblies.


 As I need to send the application updates to the customers over an expensive satellite link, I try to don't send the dlls that hasn't changed, and I'm wondering if FdoExtension.dll that you include on every daily build really changes, or I can just update MapSuiteCore.dll and WpfDesktopEdition.dll without send the FdoExtension.dll too.


 Does change GeoApi and NetTopologySuite change daily as well?


 



#2

 


Carlos,
 
GeoAPI and NetTopologySuite does not change daily, we just copy the same file from dependency folder and add it to package. FdoExtension will be built every day, but actually the source code of it doesn’t change frequently, so you can just update MapSuiteCore.DLL and WpfDesktopEdition.DLL, but if you want to 100% not any problem, I am afraid you’d better update FdoExtension as well.
 
Thanks,
James

#3

Thanks James, 
  
  Is there any place where we can read a rough changelog on the daily builds changes such as: 
  
  dd/mm/yyyy build 4.5.xx.xx: 
    - MapSuiteCore: - Minor bugfixes on blablabla 
                            - XXXX feature added 
    - WPFDesktopEdition: Added support to xxxx 
                                    Ticked 12345 addressed solving xxxx 
  
 Something just short, simple and general maybe coming from your internal version control system? 


#4

Carlos, 
  
 We do want to have the daily change log but just not ready. We had a plan to partly public our internal issue tracking system, not only provide the status of every issue, but also let the customer vote what is the biggest bug or most wanted new feature so we can modify the priorities. It’s on the list and once we have enough resources, we will do it. Thanks for your suggestions anyway!  
  
 Ben

#5

Hi Ben, 
  
  One more question on WPF Desktop assemblies. Why the daily builds only updates the "FileVersion" and "ProductVersion" (4.5.107.0), but not the AssemblyVersion (4.5.0.0), that is the only one that can be read by reflection? Is there any special reason for it? 
  
 Carlos.

#6

Hi Carlos, 
  
 For Strong Named Assemblies, it’s breaking change to change the Assembly Version. So for example I have App.exe referencing MapSuiteCore.dll, if I replace the existing MapSuiteCore.dll with a different Assembly Version, the App.exe cannot run anymore without a recompile. As a result, we don’t change the Assembly Version unless in the big public releases(May 1st and November 1st). And that’s also why for every product we provide both Strong Named Version and Non Strong Named Version, as Non Strong Named Version doesn’t have this issue.  
  
 Thanks, 
  
 James

#7

Hi James, 
  
  I was guessing so, but what’s the point of changing a DLL without recompile? if you change a dll is normally for take advantage of new features, that you will need to refer in the code, and hence recompile. 
  Beside that, as Non Strong Named Assemblies does not have this issue, it would be nice if them had their Assembly version modified, woulnd’t them? 
   
  Carlos.

#8

Carlos,



So here is a short history for this. We didn’t have assemblies strong named in Map Suite 2.0 until a user requested that. We then added the strong name and update both of Assembly version and File Version in the Weekly Build but not many days later, some users complains they have the “new assembly not compatible issue”, when sending a new Map Suite Assembly with a bug fixed directly to his customer and want the customer to simply replace the old one to make the app work. From then on we knew that to avoid breaking change, we should never change the Assembly version, and that’s why from Map Suite 3.0, we kept the Assembly Version the same all the time. 


Everything goes fine until Map Suite 4.0 is released when many customers asked why the assembly version is Still 3.0, which makes them difficult to force people deploy the latest version.  For detail please see here. As a result we have the current strategy: Only update the Assembly Version in the main release, Update File Version and Keep Assembly Version the same in Daily Build. At the same time provide the Non Strong Named version for the users don’t want versioning breaking change. As the Assembly Version doesn’t make too much difference with FileVersion for Non Strong Name Assemblies, we use the same strategy as the Strong Name one (Update Assembly Version every half year) to make it easier for us. 


So you can see it is a Compromise trying to meet all kinds of requirements.  J We might keep doing changes when new requirement comes. 


Thanks,


Ben



#9

Hi Ben, 
  
  Thanks a lot for your detailed explanation. I see your point now, and agree with you it’s dificult to fulfill everybody’s expectations, as everyone has their own scenario with their own particularities. 
  Please consider to update the Assembly Version in the Non Strong Name Assemblies if someone else is interested. I’ll find a workarrond for using the file version instead of the assembly version only for your assemblies in my app-updates module. 
  
  Regards, 
  
 Carlos.

#10

Carlos, 
  
 We will consider that. If customers are interested and there is no breaking change for other customers (so nobody is taking the advantage of the existing Assembly Version strategy for non strong named assemblies), we can definitely do it. 
  
 Thanks, 
  
 Ben