SolidWorks 2008 Woes
I like it when Matt Lombard is pissed. Because when he is pissed, he takes it out on his keyboard which results in a long and interesting post on his blog. His post describes the reasons why a majority of SolidWorks users are not upgrading to SolidWorks 2008.
It's not only users who are unhappy with the revamping that has happenned in SolidWorks 2008. Developers like us have our own set of complaints as well. Up untill SolidWorks 2007, add-ins developed for earlier versions of SolidWorks (2001, when we first started writing add-ins) could be loaded and used without a problem. Every year, when a new version of SolidWorks was released, we had to do minor tweaks to our code to make it work with previous and the latest version, test it and release the add-in.
But with SolidWorks 2008, all hell broke loose. They used a new development environment from Microsoft, most probably to arrive at the whiz bang GUI among other things, and our good old add-ins started crashing. An announcement from SolidWorks read as follows:
"SolidWorks 2008 will block the loading of 3rd party SolidWorks add-ins created using the old style MFC 4.2 extension DLL architecture. Testing of SolidWorks 2008 has revealed severe instability with add-ins created using this architecture ...... This will affect any Solution Partner or internally developed add-in products using MFC 4.2 extension DLL architecture when used in conjunction with SolidWorks 2008. This does not affect SolidWorks 2007 and earlier releases."
Little wonder that SolidWorks users are still clinging on to 2007. Developers are not too keen on spending their resources to rewrite their SolidWorks add-ins from ground up to suit the 2008 architecture and users are not pestering them to do so because not many are using 2008 in the first place.
I submitted a Service Request to SolidWorks that would make it easier for developers to port their code to the new architecture, instead of rewriting everything. This was three months ago. The last time I checked, the status of my SR was "Under review (Future Release)", inspite of them setting the "Customer Impact" to "High". I am now beginning to get a sinking feeling that what I asked in my SR is technically impossible, thanks to Microsoft and their ways of forcing everyone to use their latest stuff.
At the moment the 3D Parametric CAD market is poised very delicately. Now would be the worst time to piss off customers.
Ironically, today SYCODE released four new AutoCAD 3D interoperability add-ins for SolidWorks and none of them work with SolidWorks 2008.
It's not only users who are unhappy with the revamping that has happenned in SolidWorks 2008. Developers like us have our own set of complaints as well. Up untill SolidWorks 2007, add-ins developed for earlier versions of SolidWorks (2001, when we first started writing add-ins) could be loaded and used without a problem. Every year, when a new version of SolidWorks was released, we had to do minor tweaks to our code to make it work with previous and the latest version, test it and release the add-in.
But with SolidWorks 2008, all hell broke loose. They used a new development environment from Microsoft, most probably to arrive at the whiz bang GUI among other things, and our good old add-ins started crashing. An announcement from SolidWorks read as follows:
"SolidWorks 2008 will block the loading of 3rd party SolidWorks add-ins created using the old style MFC 4.2 extension DLL architecture. Testing of SolidWorks 2008 has revealed severe instability with add-ins created using this architecture ...
Little wonder that SolidWorks users are still clinging on to 2007. Developers are not too keen on spending their resources to rewrite their SolidWorks add-ins from ground up to suit the 2008 architecture and users are not pestering them to do so because not many are using 2008 in the first place.
I submitted a Service Request to SolidWorks that would make it easier for developers to port their code to the new architecture, instead of rewriting everything. This was three months ago. The last time I checked, the status of my SR was "Under review (Future Release)", inspite of them setting the "Customer Impact" to "High". I am now beginning to get a sinking feeling that what I asked in my SR is technically impossible, thanks to Microsoft and their ways of forcing everyone to use their latest stuff.
At the moment the 3D Parametric CAD market is poised very delicately. Now would be the worst time to piss off customers.
Ironically, today SYCODE released four new AutoCAD 3D interoperability add-ins for SolidWorks and none of them work with SolidWorks 2008.
posted by Deelip Menezes at
2:10 PM
10 Comments:
You're right: this could be a tipping point for SolidWorks: Inventor is outselling it, Alibre is underpricing it, and now an incompatible update is released.
This might explain SolidWorks offering "sale" prices now until the end of the year -- with the catch that you have to contact their sales people to learn the size of deduction for which you qualify.
Looking back in history, AutoCAD Release 13 was a huge hiccough that Autodesk eventually overcame. After shipping a dozen R13 patches, Autodesk finally shipped Release 14, which ended up becaming one of the all-time favorite releases.
By
ralphg, At
9:23 PM, December 05, 2007
I don't buy this argument. SolidWorks has been asking addin developers to switch to COM style addin since SW2003. They were supposed to quit supporting MFC style addin from SW2004. People who took that warning seriously and moved to COM style addin do have addin available on SW2008.
I would say SolidWorks spoiled addin developers by supporting MFC style addin till SW2007.
Why are you blaming SolidWorks? Its Microsoft. Since Microsoft changed the version of the system dlls, your application is not working. SolidWorks at least has a courtesy to show a message box when you try to load MFC style addin SW2008. If an addin developer had shown some responsibility by not totally depending on SolidWorks for all system resources (by making it outproc or COM addin), there would not have been talks about incompatibility.
By
Anonymous, At
2:54 AM, December 06, 2007
FWIW, ArchiCAD by Graphisoft changes their API with every new release. As a result, each add-on has to be recompiled for every new version.
Some commercial add-on-developers do their best to keep up with the latest release, but many others have stopped further development for their plugin. Many end user rely on external plugins for their daily practice and have no possibility to do anything about it, as the plugins are only DLLs... obviously. They can only keep using them in an older release of their main CAD software.
And now they are on a yearly release too!
As usual, the end-user is not helped with this evolution.
By
stefkeB, At
3:06 PM, December 11, 2007
Vicky, point taken. However, some add-ins are not that simple. They internally use other libraries which can in turn use MFC and a ton of other things. Then you may or may not have the source code to modify these libraries in the first place. I am not saying that it cannot be done. Just that developers have more pressing things to do rather than support a new version which is not yet implemented by users in a big way.
Stefan, recompilation is not an issue at all. We have been doing that with our SolidWorks add-ins for years. The problem arises when we have to completely rewrite stuff.
By
Deelip Menezes, At
3:23 PM, December 11, 2007
"Stefan, recompilation is not an issue at all. We have been doing that with our SolidWorks add-ins for years. The problem arises when we have to completely rewrite stuff."
As a supplier, you can ask the end-users to pay for an upgrade to a new version of the plugin, if serious costs are involved. But as an end-user, the 'new' version of the plugin on which they rely might as well be not developed any further and be stuck with a particular version of the host software.
By
stefkeB, At
1:55 PM, December 13, 2007
"However, some add-ins are not that simple. They internally use other libraries which can in turn use MFC and a ton of other things"
Deelip, I understand what you say and a simple solution to it is to have a lightweight COM addin which would delegate all SW connection calls. In theory only two calls change; connection and disconnection. Rest all remains the same.
Anyway, my point is, there is a limit on what SolidWorks could have done. Microsoft has done drastic changes recently and unless you do something to your program, its not guaranteed to work in the future. For example, if you want your program to work on 64bit and Vista you have to build it using Visual Studio 2005. If you want to do any development on 64bit machine or Vista you have to install Visual Studio 2005. Moreover, there are other things like OpenGL is not supported in Vista, DAO is not supported in 64 bit, you cannot write to program files directory or to the HKLM registry in Vista, etc. Because of all such incompatibilities introduced recently by MS, it is much likely that your program will not work on latest OSs and even if it does it is not likely to run in future upgrades of MS OS. So, irrespective of whether your product is an addin to SolidWorks or a standalone application, most likely it has to be upgraded to run on latest OSs.You cannot tell customer that if they want to use your product then they have to use it on XP. That is exactly what SolidWorks did. Made their product compatible with new OS.
Having said all this, I do agree that its not easy on small-time developers. Many people like us, who are not so big, are in a strange situation where we are spending more on just making your program compatible with the recent changes from MS than adding real value to the user. It is really difficult to justify the cost for annual maintenance contract to the user.
By
Anonymous, At
2:41 AM, December 18, 2007
Vicky, I count agree with you more.
I need to discuss something with you. Please contact me offline at deelip (at) sycode (dot) com
By
Deelip Menezes, At
9:44 AM, December 18, 2007
you make a living by writing add ins to solidworks and yet slag them off? You're very clever. Or are Autodesk paying you to post this bullshit?
Lets all live in the past and drive Model T Fords, live in caves and complain at anything New and original. Get with the times and stop complaining. SolidWorks 2008 is incredibly stable and great to use.
By
Anonymous, At
9:18 PM, December 21, 2007
"you make a living by writing add ins to solidworks and yet slag them off?"
Like any good businessman I will spend my resources on things that have a greater chance of getting me money. In the past week, we have suddenly started receiving inquiries about SolidWorks 2008 support. I have no idea why the sudden change. We have already started work on this and our add-ins should be SolidWorks 2008 ready soon.
"are Autodesk paying you to post this bullshit?"
No, although I hope that they would seriously consider it. On the contrary I am paying them to be their partner.
By the way, our SolidWorks add-ins do not yet support 64-bit as yet. And neither do our AutoCAD plug-ins. And this is because there has been virtually no demand for 64-bit support, not for any other reason.
By
Deelip Menezes, At
12:09 AM, December 22, 2007
The Guys from SolidWorks are just a bunch of incompetent assholes. No engineering background or knowledge, no research, no productpride, no efficiency philosophy. I think being a France company,with solidworks they probably tried to internally sabotage companies productivity and make them loose money by using their software program.
I wonder when management of the companies that use Solidworks will see the light or start growing the gots to just kick Solidworks out their company.
Solidworks is just another software Cancer you should always try to get rid off or it will kill you.
By
Anonymous, At
2:05 AM, June 19, 2011
Post a Comment
Subscribe to Post Comments [Atom]
<< Home