This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi all - We ran into a new problem with the Mindscape LightSpeed dll. We had been running the version 4 nightly build from Mar 6th (0306) with no problems, upgraded to the 0420 build but did not deploy until recently so got the 0606 nightly build and attempted to deploy the new update yesterday. We use the Click Once platform to deploy our application to client PCs and all client PCs are running XP, if that matters. When we ran the installer, we got the following message: "Unable to install or run the application. The application requires Microsoft.SqlServer.Types Version 10.0.0.0 in the GAC" Digging deeper we found Mindscape.LightSpeed was the module that referenced this DLL. We dropped back to the 0420 build to see if that fixed it, but eventually had to go to the 0306 build to get it to work. We have run into something similar with your product when we use ILMerge to create one monolithic program from all the libraries and such, but were able to build small "dummy" DLLs (~4k each) with the proper version number and include those to get ILMerge to work. Examples include IBM.Data.DB2, MySql.Data and System.Data.Sqlite. Since we never actually use anything from those libraries it works well. We tried a similar approach to get around this latest limitation but had no luck. So why is this required when we don't actually use it? And can you fix it so it is not required? Thanks, Dave |
|
|
We've also been seeing issues with this dependency following recent changes. Is this a dependency we actually need to add (when using Sql2008 provider)?
|
|
|
This assembly is required when using the Sql2008 provider but should only be an issue at runtime (and the assembly will presumably be GAC'ed). We have certainly seen issues where something inspects for referenced assemblies and then tries to load those (to inspect for their dependancies) but unfortunately this isnt something we can control since we need those references for the provider functionality. @dnewman: From what you have said this is an issue that pops up when you are trying to install the click-once application (as in the error would be generated by the click once installer itself?). If its possible to send through a project we could use to reproduce this quicker that would be very useful (either email it through or attach it) otherwise I will look at trying to reproduce this here. I am also adding in a slight change which will be in the next nightly build so if you are able to check a nightly over the next few days and see if that resolves the issue that would be much appreciate. (likewise @kiwidev). As an aside we are changing the provider model slightly in 5 to reduce the dependancies we have in the core assembly which should alleviate most of these issues.
|
|
|
Dnewman, Have you unselected the assemblies you don't care about in the ClickOnce builder? http://www.mindscapehq.com/forums/thread/4390 By default Visual Studio aggressively scans assemblies for any possible reference they may have and includes them (as Jeremy noted, outside of our control. Until we buy Microsoft...) Given the thread was with you last year perhaps it's something new however! John-Daniel |
|
|
"until we buy Microsoft" ... is that in the mid-term or the long-term plan, mate ;-) |
|
|
Well, seeing as Microsoft is free we wouldn't exactly be buying Microsoft product. What we would be paying for is Microsoft service and support, and to get the kind of service we get from the folks here at Mindscape we would end up paying far more than we could get authorization to spend -- if it's even possible to get the same level of support. Say what you will about either MS company, with Microsoft we usually have fewer options for getting help when something goes awry. We don't have pockets deep enough for Microsoft to even notice us, so we generally have the user community and if the product is actually broken you just have to figure out a workaround on your own and live with that. We still consider Microsoft's Entity Framework every year when the renewal comes around, but we just re-upped for another year so switching is definitely not in the short-term or mid-term plan. You never know what another year might bring, but for now we're happy with what we get for our money with the LightSpeed product. Dave |
|
|
This is a response to Jeremy's post, not my own. Is there no nesting on a thread? Apparently this is just linear with the next post always a response to the latest one... Anyway, Jeremy stated "This assembly is required when using the Sql2008 provider but should only be an issue at runtime (and the assembly will presumably be GAC'ed)." The last part is the problem. We reference the Midscape.LightSpeed dll in our WCF client that has no knowledge of SQL types, nor should it. We are using the CLR types generated by LightSpeed at the client level and SQL is only on the server level. Why are you presuming any server-level assembly will be in the client machine's GAC? Apparently something changed since Mar 6 in the way you reference the Microsoft.SqlServer.Types DLL as we have no problems with the nightly build of that date. Something changed on your side between there and Apr 20. Responding to John-Daniel, I had forgotten about that post but that is not the problem. Your library expects to find the SqlServer.Types DLL in the GAC on the local machine, not included as part of the build. We tried including this in the build and referencing the local copy and it still didn't work for us. Cheers, Dave Newman |
|
|
I have the exact same problem. http://www.mindscapehq.com/forums/thread/346034 The only solution that we found was to shipped the library to the client with our package. |
|
|
I have added a change in to the nightlies which hopefully may resolve this - please let me know if the problem is still present after using a nightly from 19/6 onwards.
|
|
|
That seems to have done the trick! At least my program now installs and runs without complaint on the client machine. Thanks, I'll let you know if we see anything out of the ordinary but the 6/20 build seems to be working as expected. Dave |
|