Call me crazy, but I just downloaded the 4.0 production release, and the installation labels it as 3.0, including the installation name, the text header, and the installation directory it creates. Is this just not updated yet, or did I get a bad production download?
4.0 installer saying 3.0?
Kevin,
Thanks for your post and I am sorry to make you confusing.
The 4.0 production release is just a branch of 3.0 versions, its assembly version is still 3.0, only the File Version is 4.0. So, as you already saw, the installer path the registry, the sample logo etcs are still 3.0 marked.
Any more questions just feel free to let me know.
Thanks.
Yale
Are you saying that you are coming out with a major release, and you are not going to change the assembly version numbers?
Ted,
Yes, we did not change the assembly version number to avoid breaking change.
Thanks.
Yale
This is very frustrating. When the version number was not changed from 3.0 to 3.1 (even though there were breaking changes), it was acknowledged as a mistake. Now you are doing a Major release, and still not changing.
First, it makes it impossible to have two versions in the GAC. But, OK… I get it… the GAC is bad. So we change our install and now install MapSuite local for every one of our products… ie, make the user download it 6 times. Then a competitor that uses ThinkGeo comes along, and they don’t play by the rules. They install into the GAC. And, they are stiill installing file version 3.1.299. Because the assembly versions are the same, our applications will now start using the copy in the GAC, instead of the local copy (yes, that is the order of priority). And, while there are no breaking code changes, going forward, there are certainly breaking code changes going backwards.
We have no way to defend ourselves against this kind of inadvertent or malicious use of your product by our competitor.
I agree with Ted, this is a bit of a nightmare. I understand why ThinkGeo does this the way it does, but it certainly is a pain.
Not to mention things like this: I get the latest version of MapSuite Desktop Edition. All the core DLL’s are bumped to 4.0.0; perfect. I copy the MapSuiteFDOExtensionx86 folder to my System32 like I always do, and I’m off and running. Oh wait… Everything in the MapSuiteFdoExtensionx86 folder is old. I also get the latest version of the Spatial Data Extension, and check the provided MapSuiteFdoExtensionx86 and wouldn’t ya know it… its up to date! But then I go look at the provided core DLL’s, and they’re 3.1.299! So the HowDoISamples are referencing an old MapSuiteCore and DesktopEdition.
And to add to this, bumping everything to “4.0.0” and calling it “Map Suite Desktop Edition 4.0.0” (per your site) but still referring to it as 3.0 is confusing beyond all belief.
Hi Kevin,
Have to agree with you and Ted. I am simply stunned. This shows a serious and fundimental lack of understanding of version control and the problems faced by developers when deploying mass market software.
We are now going to have re-think our entire deployment strategy and module design to cope with this. I had a quick chat with some guys I know in the ,NET team, at least it brightened up their afternoon, one ex-pat described it as "an amusing and spirted interpretation of version control which conflicts with the way the GAC is intended to operate and could well lead to premature hair loss!"
John
I see all your problems. I’m very sorry for the confusing.
I think here is the key point: Some of our customers have had some apps already in application, so what they expected is to grab the latest dll, replace the old one without any compilation and everything should then work fine. But some other customers like you guys have your own package and need to redistribute ThinkGeo assemblies, which means you want the assemblies to be strong named and has a different assembly version so you can make sure your latest application only works with the latest ThinkGeo Assemblies. And some other developers are still on developing phase, making the assembly version different will also be helpful for them as that reduces the possibility for referencing a wrong assembly.
Keeping the same Assembly Version like what we are doing now only cares about the first kind of customers who have had apps in application but not work for the guys who need the redistributions, and might bring some trouble to the guys who are still under developing.
We will have a discussion and take seriously on your issues. Sorry for the confusing again and we will keep you updated on this.
Thanks,
Ben
For what it is worth, there is no other vendor that I deal with or am aware of that operates with a structure that lets a deployed application be updated by just dropping in new third-party components. I can understand why you might want to operate this way witihin significant product releases, and based upon our experiences with your philosophy on this, we do the same thing with third-party developers that use our components. But, as a software author, I would never consider deploying a new set of third-party components to updated my in-place application in a production environment.
I like it when I don’t have to make significant code changes between revisions, and I applaud your efforts in avoiding breaking changes during the past several months. But, I have no reservation at all in recompiling my product to take advantage of a new version of a third-party component.
Guys,
I am just back and catching up wit this topic. I was not aware that the gac had priority over the local copy. Microsoft really screwed this up. In any event I am taking this up now and we will get this fixed asap and have a new version out. WhY I need from you guys is to make suggestions as to what would make your life easier. For many of our customers they need to be able to drop in compatability. Of course we need the gac side of things handled as well. I invite suggestions and discussion.
1. We need to handle the daily builds versioning.
2 we need to handle drop in compatability
3 we need to handle the gac well
4 we will be keeping 100% backward compatability.
5 we need to support mid cycle production build for emergency bug fixes
My thoughts initially would be to publish strong named and non strong names versions. Is it possible for anyone to strong name the assemble after it is compiled.? In this way you could strong name it yourself. It has been while since I did this and it doesn’t sound right.
On the version issue there is a history to this. Version 3 vas a whole new platform versus 2. So you can think of is version 4 is a continuation on the version 3 platform. That is why it stayed the same, we didn’t notice until late in the cycle that the directories and registry keys all had 3 in them. We were not sure if people wanted to overwrite 3 or not. Our versioning is goi g to be releases very may and november and the version will go up .5 for each so a point each year. In this way major release is really a smooth progression over time. We want our releases predictable and smooth. We have a couple options…
1 for each 6 month release we could use different directories In the start menu. You would be able to keep versions separate.
2 we could keep them the same and remove the version from the directory. You would need to remove e previous version to install the new one. Since things are comparable this is possible.
Is is out first may release so I expected some snafus but we are willing to do whatever makes the most sense. Please let us know your feedback. Constructive feedback please :-)
David
David,
Thanks for your lengthy response, and understanding the developer side of this issue. First off I want to say I do completely understand why you keep the assembly versions the same; it makes sense for drop in additions. However, we often have to change the code up to take advantage of new functionality anyways, so a rebuild becomes a common occurance. Also, when we release 5+ apps that all use the same ThinkGeo DLL's out of the GAC, it makes it impossible to keep them running on separate versions of the DLL's for which they are built. I have no way of keeping the 3.1.299 and the 4.0.0 dll's in the GAC at the same time. So the moment I install a 4.0.0 DLL in the GAC, I will not be able to roll it back to 3.1.299 for the other apps that have only been tested with that version.
Going forward, I'd suggest doing a "strongly version" and "weakly versioned" set of DLL's for the different applications of your libraries. This would cater to both types of users of your code, and perhaps I could sleep without headaches at night :)\
And to answer your question, at least in our case, we could change the assembly version of the DLL's, but I don't think we can make them "strongly named" on the fly. We decided not to sign them with a specific assembly version because if you ever release a DLLwith assembly version less than what we've set our own as, we'd be screwed.
I'll echo Kevin's thoughts, pretty much. However, I don't really think that keeping the version the same across your two semi-annual releases is very important. I think it would be poor practice to encourage developers to drop in new supporting dll's into an app that wasn't at lease compiled against them, and more likely, optimized to take advantage of some new feature. Otherwise, why even bother running on the new dll's. Just because ThinkGeo might have done something under the hood to make things faster?
I would even go a little further. I don't think you need to commit to non-breaking changes between these semi-annual releases, and especially between annual releases. Sure... nobody wants to see the version 2 to version 3 scope of change, and any breaking change needs to really be thought out. But, your team is cerainly much better than mine (and I think I have a pretty good team), if you can say that the way you have implemented things now will still look like the best option a year from now, and that there won't be some place down that road where you compromise your new product because you have to try and maintain legacy compatibility. Sounds like how Windows got bloated, to me.
Edit -- And, no... we are not willing to try and set versions or strong naming on your assemblies.
Guys,
We will release a timeline and list of changes in about 24 hours. I will outline all the proposed changes as they relate to the strong naming issues and that does include updating the assembly version number. There are some other changes that flow directly out of this new line of release thinking and we will share our ideas and get your feedback.
David
Guys,
We have outlined the changes necessary and have a target date of June 14th. Let me know if you have any questions or comments.
1. Side by Side versions - Since each strong named major version will be incompatible with the previous one we need to support side by side installation. This means each major 6 month release will install into a separate directory and separate start menu position. You will no longer need to un-install the previous version.
2. Update Verbiage - We will be sure to update all the version numbers in the various place inside the packages such as documentation, website, and samples.
3. Strong and Weak Versions - We will provide strong named and non strong named versions with every product. This will allow each developer to choose the model that best fits their needs
4. Assembly Version - The assembly version will be updated with each major six month release. The assembly version will stay the same for each daily build where only the file version will change. We are open to suggestions if this does not fit everyones needs. please speak up now though :-)
5. Roll-up Unmanaged Wrappers - Currently we have a number of wrapper assemblies that accompany our unmanaged dlls. We will wrap all of them into one assembly and be sure to include this in our auto build process. This will cut down the number of assemblies that need to be deployed.
6. Version Unmanaged DLL Folders - Starting with version 4.0 we will version the unmanaged DLLs that reside in the system32 directory (and for 64bit). Each six month release will be the trigger to create a new folder. Since these assemblies rarely change we will include logic to attempt to use previous versions if we do not find the latest version. All of these will be deployable through the merge modules which will get updated on each major release as well. This will ensure side by side deployment will work between versions.
David
David, I’m ok with this. But did it get implemented? If so, I’m ready to update this week. Otherwise, will just have to sit tight. There is another application (from a competitor) that uses 3.0.0 in the GAC, and it has us shut down for our release.
Hi,
We have a big trouble here; my customer is using 2 products done with MapSuite;
one with MS3; one with MS4
the issue is that the one with MS3 does no longer work since the one with MS4 has been installed.
it looks like the one with MS4 is overwritting the one with MS3 in the GAC, because it’s signed 3.0
Help, we are in emergency, unistalling both application do not solve the problem.
Patrick.
I think I am in the same boat as many others here... We need the ability for side by side installs of MS3 and MS4 on client and development machines.
Waiting for the new MS4 install - In the mean time, I can't abandon the MS3 clients.
Guys,
We have released the changes we outlined in the post above. This means that the new assemblies will have a signed 4.0.0.0 version number. You can read the details at the link below. Note that you need to download the new full install. the daily builds will not be enough for this update. We are cleaning them up as we speak but wanted to release the full editions with installer on time.
To Patrick’s issues you should not be able to install 3.0.0.0 into the GAC and the new 4.0.0.0 at the same time. If you still have issues Patrick please let me know.
Details:
gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/16/aft/7655/afv/topic/Default.aspx
David
David, I assume you mean you can "now" install 3.0.0.0 in the GAC and 4.0.0.0 at the same time, and not "not" ?
You might want to check the internal names associated with the X86 ECW merge module. And the X86 and X64 names are not consistent on the projection modules. These are just internal names, so I don’t think there is any issue other aesthetics :)