ThinkGeo.com    |     Documentation    |     Premium Support

Automated Tests and SqlServerSpatial110.dll

Greetings,



We have been using TFS 2012 to do our builds and automated testing on our mapping project for some time without issue. Recently we added the SqlServerSpatial110.dll. We were able to deploy to our servers using the SqlServerSpatial110.dll’s functionality and by following the directions found in the “UnmanagedAssembliesDeploymentGuide.txt” without any issue, but our automated tests fail on any method that uses that dll’s functionality. 



We have followed the instructions for the unmanaged assemblies on our build server the same as we did on our web servers, but our tests continue to fail. We are using the 32bit scenario on a 64bit machine. Below is the dump of the test failure. Any other ideas we could try?



System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)

System.Reflection.Assembly.LoadFrom(String assemblyFile)

ThinkGeo.MapSuite.Core.SqlTypesGeometryHelper.9jc=()

ThinkGeo.MapSuite.Core.Feature.get_CanMakeValid()



Thanks,

Chuck

Hi Chuck,



Would you please check the Microsoft Visual C++ 2010 Runtime have installed in your machine? here is the link related with it, by check the MSVCR100 dlls. wiki.thinkgeo.com/wiki/Map_S…cies_Guide



If the issue persists, please feel free to let us know.
Thanks,
Troy




Thanks Troy. I verified that the  MSVCR100.dll and MSVCP100.dll are the same between our build servers and our web servers. The dll’s exist in both the System32 and SysWOW64 on both machines with their respective dll.



Something that is different between the server is that the “d” dll’s do not exist. However, when I try and run the MS Redistribution package, the software is already installed. I went ahead and chose the repair option, but it still did not install the msvcp100d.dll or msvcr100d.dll.



I do see that on our web servers we have Map Suite 7.0 installed. Is that required for our build server as well? Again, everything worked fine until we tried to use some functionality that required SqlServerSpatial110.dll.



Thanks,

Chuck

Hi Chuck,



The msvcp100d.dll should not the problem as it’s an assembly for debug and also I don’t think we need to install the Map Suite 7.0  on the build server. But I think we need to try the below ways:


        
  • I checked the exception again and found we are using CanMakeValid method, so could you verify the “Microsoft.SqlServer.Types.dll” is under the right position? we can put it together with SqlServerSpatial110.dll or just in the Bin folder of application.

  •     
  • Double check the SqlServerSpatial110.dll is under the correct position? please comparing them with the “project Bin Directory” item in the dependencies matrix


If the issue persists, maybe install the Map Suite Unmanaged Dependencies xxx.msi is worth to try, or let us know.

Thanks,

Troy

Hi Troy,



As I mentioned before, the SqlServerSpatial110.dll is in the correct directories as specified in the link your provided and the UnmanagedAssemblies text document in the install. I’ll try moving it to the bin folder on our build server and see if that works.



If I wanted to try the Map Suite Unmanaged Dependencies, where would I get that msi? I don’t find it in my install.



Thanks,

Chuck

Hi Chuck,



I am caring does the Microsoft.SqlServer.Types.dll file locate in your Bin folder or you are referring it in your build server? since this assembly is required for using CanMakeValid method.



As for the Map Suite Unmanaged Dependencies installer, we can get it in the daily build package by accessing in ThinkGeo Customer Portal

Thanks,

Troy

Hi Troy,



I was out most of last week, so didn’t get to work on this much. However, I did install the unmanaged dll’s on our build server and rebooted and that did not resolve the issue.



In answer to your second question, the Microsoft.SqlServer.Types.dll is in the bin of our project and so also shows up in the bin on the build server.



Any other ideas you have?



Thanks,

Chuk

Hi Chuk, 
  
 Sorry Troy is busy for new 8.0 publish these days so we reply you late. 
  
 I think our Unmanaged Dependencies msi should contains all necessary references for our product, so maybe the build server miss some important dlls? I am not sure that, but I think maybe you can install Microsoft Visual C++ 2010 Runtime package again, it’s just another try. 
  
 We will going on try to find what missed in the discussion before. 
  
 Regards, 
  
 Don

We just upgraded to TFS 2013 and after updating the configuration, all our tests are passing fine. Thank you for all your help. Although I still don’t know what caused this issue. We did switch from use MSTest to Visual Studio Test Runner. I’m not sure if that is related though.

Hi Chuck, 
  
 I am glad to hear that works for you. 
  
 This type issues always related with environment and it’s hard to find the exactly reason. 
  
 But I guess maybe you’re right, the test tool should be related with it. 
  
 Regards, 
  
 Don