I’m surprised you didn’t see it. it’s in the source code, it can be seen through a reflection tool, I can create a sub class and override that method in a test project. Here below is that assembly in ILSpy. Can you check again if you were using the correct assembly? 
We had a strict API test to avoid API breaking change in every release. I agree with you that sometime we might have feature breaking change, like an event was raised in a previous version but not in a newer version. We tried to avoid that but I admitted that happened sometimes, as there is not a tool to detect it and our UnitTest doesn’t cover all the APIs/Scenarios.
The assembly I sent to you was based on 9.0.0.100, as we are reluctantly to make changes in release branch, this one should have few changes with 9.0.0.66. Let me create a strong name version and have another try.
OutOfMemoryException
Interesting, so it is.
But it was not me that was looking for it, this is a compiler error I get when I substitute the old 66 DesktopEdition.dll with your new 100 version. I switch back, the error goes away. Just tried it again, same result. The compiler is not happy, and the last time such a thing happened with a single DLL update it only broke again due to references between your assemblies after I figured out how to restructure my code for the change. So when it happened on this version, I didn’t look further. At this point, I’m not sure why it’s giving that error since the method is obviously there. And to offer further confusion, if I remove the old overload and see what intellisense says, it provides the same signature again, and then the compiler complains the same way again. So VS “sees” it, but the compiler does not. I wonder if it’s somehow a invalid/inaccurate response to the lack of strong naming in the new assembly?
So, just swapping in/out the 66/100 assemblies causes it to come and go, with no other changes. But using several different reflection options, they all show the overload signature remains intact. Wow, not sure what to say on that one, except the compiler is still offering the same error…
Edit Update:
On a hunch, I decided to “fix” that error by simply removing override and, as expected, then got a complaint about hiding the method in the base class. Rename to get past that, and then everything went off the rails. Line after line of “does not contain”, “cannot convert”, etc. Then the final error, “Assembly generation failed – Referenced assembly ‘DesktopEdition’ does not have a strong name”.
Something about the replacement of that assembly with a non-strong named assembly appears to have somehow triggered the fist singular error that completely errored out the compiler, preventing it from continuing, and blocked the deluge of errors including the real root cause, lack of strong name. I don’t see any other explanation than that the compiler choked in an unexpected way due to the substitution…
As you said, it might be an invalid response to the lack of strong name. I’ve sent you the new strong named DesktopEdition.dll through email. I attached its dependencies as well even just replacing single DesktopEdition.dll works in my test. Again I suggest to only replace one assembly to avoid unnecessary uncertainties. Let me know what it turns out. Please be aware the exception is still supposed to be thrown with the new assembly, only debug info will be dumped to the log file.
In the same way that an OOM is sometimes reported when that is not the real cause, I believe that VS was unhappy with the lack of strong name, DrawCore error was it’s imprecise way of complaining about that problem. In any case, replacing only the DE.DLL works just fine in this strong named version. I’ll move forward with the test, and thank you for your help.
It will only log to the log file after OOM is thrown, I catch and rethrow the same exception but add dumping code in. I also fixed a potential issue (A BufferedGraphicsContext object is created in the SizeChanged event but the old object was not disposed, I added the Dispose() to the old object) which might lead to your issue. All the changes are based on source 9.0.0.100.
So if the exception can never be thrown, the above change might do the trick. Otherwise send me the generated log and I can dig more.
Unfortunately, we just had a new report of this problem. It was confirmed as running with the 9.5.0.100 version build.
Here is the call stack.
System.OutOfMemoryException: Out of memory.
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.LBQ=(Bitmap bitmap, Int32 x, Int32 y, Overlay overlay, String id)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.TxQ=(Graphics graphics, RectangleShape extent)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.KxQ=(RectangleShape drawingExtent, RectangleShape extent)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.TBQ=(RectangleShape extent)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.ShQ=(Int32 delayInterval, RectangleShape extent)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.Refresh(RectangleShape extent, IEnumerable`1 overlays)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.Refresh(RectangleShape extent, Overlay overlay)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.Refresh(Overlay overlay)
So it is the first time you got this OOM in the last 18 months?
We have the latest Map Suite 10.0 released which has many bug fixes and new features, and we would highly recommend you to upgrade to that version. Here shows how to upgrade from 9.0 to 10.0. http://wiki.thinkgeo.com/wiki/map_suite_10_upgrade_guide
We are already working on moving to your v10 for our next release. I’ve been following your migration document, but ran into what I believe to be the last few remaining problems with adapting to the structural changes. My question can be seen at:
But we just rolled out a release, and there is no way we are going to adopt such a major update for that release. In fact, the risk imposed by the major structural changes in v10 is why we specifically decided to keep the build we thought fixed this problem for the release we just rolled out.
And I have confirmed the site reporting the problem is running our new release, and has the correct custom ThinkGeo build.
Oh, and in answer to your other question, yes, it’s been over a year since the last report. This is one of the worst sites from our last discussions on the matter, and my first expectation was that it had somehow gotten rolled back to the old version. But no, it’s running the 9.5.0.100 version.
Any ideas on how to proceed? Does the new call stack provide any new insights? The signatures appear different than before (and by more than obfuscation), but that could just be the effect of the changes that were made to fix it last time. I don’t suppose the enhanced logging remains in the *.100 version?
Russ,
This OOM issue if hard to recreate , remember last time I created a specific version for you and it took days to recreate it? I believe this has to be done this time as well. So please either send us the log file, or we need to create a new version for you with loggers. Check my email in 2015 and you can find the specific version I sent you with loggers, I don’t think your current version 9.5.0.100 has it.
I would recommend you to upgrade to the latest 10.X version, as 9.5.0.100 is a customized version just created for you, it’s isolated in the version line and we cannot make changes based on that. If you want to stick to 9.X, please get the latest version 9.0.0.638 then which has all the changes in 9.5.0.100. However just let you know 9.X has lower priority than 10.X now so it might take longer time for the support team to get into it. Sure you can always contact sales@thinkgeo.com see if there’s a way to expedite it.
Ben
Well, bad news. We just got another identical report from another site.
And as I said, we JUST rolled our a new version, so there is no way we are patching that to v10. In fact, we just abandoned the v10 migration for our next version as well (see my other post regarding). Turns out MapEngine wasn’t even visible in the standard deployment, and I was advised to update NuGet (again). After spending days, finding incomplete docs and samples, and many additional problems, we just can’t risk the impact on our next version schedule (which is already tight).
So, back to our v10 (edit: should have said v9) patch. I was hoping the logging might be in the 9.5.0.100 build with some way to just turn it on. So I guess I’ll dig out that old logger build and see if we can get it on the sites having trouble.
The major rip up on your v10 combined with the OOM issue remaining in the 9.0 custom build puts us between a rock and a hard place for both this AND our next versions.
I created 5 customized version for you, from 9.1.0.100 to 9.5.0.100, I know maybe 3 of them have the logger on. I don’t think there is a way to turn on the 9.5.0.100 logger but I might be wrong, we should be able to find more info in the email I sent over. Anyway, we do need the logs to recreate the issues,
Yes there are many change between 9.X and 10.X. So the latest 9.0 (9.0.0.638) is another option. If you can recreate the issue with that version, it’s possible we created a specific version for you. If you can upgrade it to 10.X, I’m thinking we could integrate the logger into the master of the product.
If I’m following correctly, the latest 9.0 is 9.0.0.638, and has the presumed fix for the OOM that we should have currently in the private build 9.5.0.100. But that won’t have logging, and there is no reason to expect that it addresses the OOM at this point any more that the 9.5.0.100 we are currently running. If I am not missing something, all that would be gained by going to *.638 would be to confirm that it reproduces on the latest 9.0 build, or the unlikely outcome that it somehow fixes this new repro by chance.
The latest email I have in that chain is from you on 1/5/16 with a build that addresses the shape file regression. I don’t think it has the logging at that point. Before that is .9.1.0.175 attachment on 12/17/15 , but that one is also not looking like it would have the logging. I never did find one that was clearly containing the logging. These versions are all confusing, especially over a year later. Looks like that ends the emails that I have saved. And because it was a diagnostic test, it was never put into our source control. I’ll look through my disk backups to see what I can find, but not hopeful.
I just found strong named 9.1.0.100 on 10/6/15. I think that’s the latest with logging. But then it reoccurs to me that we are getting the exception with a new call stack in the “fix” version. So just grabbing this older logging version won’t really help since it’s the subsequent resulting fix that is currently reproducing.
We now have 3 sites reporting OOM. I’m still gathering information on the latest, but all indications are that it is in the same “Refresh” of the patched map component. And we have only just begun to deploy our latest update. I have no idea why our new version brought back the OOM, but unless something shakes out fast, we are going to need support on this right away. And as previously mentioned, I don’t see any value in replacing the patched build with the logging build, presumably it would just show the same thing as it showed last time. What we need to know right now is, what is going wrong with the patched build. And it seems that this time it’s MUCH easier and more frequent to reproduce than last time. Please advise.
Hi Russ,
Could you please create a ticket for this problem?
We can talk more detail about the special version in ticket.
Regards,
Don
Done. Ticket number is 17007
Hi Russ,
Thanks for create the ticket, our developer will reply you there.
Regards,
Don
No problem. As always, thank you for your help.
Hi Russ,
You’re welcome.
Any question please let us know.
Regards,
Don