ThinkGeo.com    |     Documentation    |     Premium Support

Proj4 deploy error

#1

I am getting the following error on a client machine when trying to use the proj4 dll.  I have verified that the mapsuiteprojectionx86.dll and proj4extensionx86.dll are in the same directory as the exe.  The deploy is an xcopy to the client machine.  Do these dll's have to be registered?  Any ideas?


 


1) Exception Information


*********************************************


Exception Type: System.IO.FileNotFoundException


Message: Could not find ProjectonExtensionX86.dll assembly.


FileName: NULL


FusionLog: NULL


Data: System.Collections.ListDictionaryInternal


TargetSite: Void OpenCore()


HelpLink: NULL


Source: MapSuiteCore


 


StackTrace Information


*********************************************


   at ThinkGeo.MapSuite.Core.Proj4Projection.OpenCore()


   at ThinkGeo.MapSuite.Core.Projection.Open()



#2

Ed,


Thanks for your post.


I do not think these dlls need to be registered when deploy to client machine. It is strange that this exception still was thrown out even you put the two DLLs in the target directory.
 
1) I think you are using an X86 OS environment, right? Can you let me know which OS exactly is for the client machine?
2) Are you using the last public release 3.1.299? I tested this case in a clean Windows Server2003 environment(x86) and works fine. So,
 
if possible, I suggest you copy the HowDoI sample to the client machine to see the Projections samples works fine or not.
Also, can you have a try to copy those two DLLs into System32 folder; it should be exactly the same with the exe folder. Just have a try on this.
 
Any more questions just feel free to let me know.
 
Thanks.
 
Yale

 

#3

Yale, 
  
 Yes, I am in the x86 environemnt, Win XP sp3.  The winformsmap is version 3.1.299.  I copied only the proj4extensionx86.dll to the windows/system32 directory and it worked on the client machine.   
  
 Is there any way to force it to be read from the target directory, as having to move the file will complicate our deploy?   
  
 Thanks, 
 Ed

#4

Yale, 
 By the way, I am using the proj dll in another class in the same project and it does not error out.  The proj code is esentially the same in both classes.  That really does not make sense. 
  
 Ed

#5

Ed,  
  
 It really seems very wield. I think in .net we can use the DLLs in the same directory folder when using DLL import.  And normally, the two DLLs should be in pair, one is a wrapper to call the other.  
  
 I have no idea about how to force it to read from the target directory. As far as I  am understanding, it should automatically search in the target directory first and then go to folder system32 if failed. 
  
 Thanks. 
  
 Yale 


#6

Ed/Yale- Was there ever a resolution to this problem? I am having the same problem. I have deployed to an x86 environment and installed the system32 dependencies. I get the same error. Interesting though that there is not a ProjectonExtensionX86.dll . Is this a typo in the error trapping? Any feedback is appreciated. Thanks 
 Eric 


#7

Eric,


Thanks for your post.
 
I am sorry I did not recreate the problem mentioned as Ed said. Yes, there is a type error in the exception message, while we should have this problem fixed in last public realease 4.0.0.0,now it should be “Could not find Proj4ExtensionX86.dll assembly.
 
Besides, I think you can find the Proj4ExtensionX86.dll in following folder, see following screenshots:
C:\Program Files\ThinkGeo\Map Suite Desktop Evaluation Edition 3.0\Developer Reference\System32\System32
 
 
 
Any more questions just feel free to let me know.
 
Thanks.
 
Yale

#8

Yale - Thanks for the info.


FYI -


I have found that just copying the system32 dependencies does not do the trick. Earlier I had deployment problems with a forms application and found the only solution was including your merge module in a setup. My current problem was trying to test a WCF service using a simple bin xcopy and using the system.zip file. Even with the zip unpack age approach the dlls are there, they just don't load and  you get the "file not found" error. I had to create a setup for my WCF service including the merge module and it works. Seems the merge module and/or setup process takes care of a dependency that simple copying does not.


BTW- I am deploying x86 builds on x64 Windows Server 2007 systems


Eric



#9

Eric,  
 The xcopy did work for me, but it was winforms.  Here is a snippet of code that i have in the Main() 
  if (System.IO.File.Exists(Application.StartupPath + "\proj4Extensionx86.dll")) 
                 { 
                      DirectoryInfo di = new DirectoryInfo(System.Environment.GetFolderPath(Environment.SpecialFolder.System)); 
  
                     if(!System.IO.File.Exists(di.FullName + "\proj4Extensionx86.dll")) 
                     { 
                         File.Copy(Application.StartupPath + "\proj4Extensionx86.dll", di.FullName + "\proj4Extensionx86.dll"); 
                       
                     } 
                 }

#10

Ed, Thanks for your sharing, I appriciate it very much. 
  
 Eric, the merge module is designed to solve the re-deploy problem for those DLLs, so it should work as expected. 
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale 


#11

Guys, 
  
 One other thing to notes is that we now ship with a managed version of proj4.  You can access it using the managedproj4projection class.  This has no external dependencies and is 100% managed.   
  
 David

#12

Is there a way to get the GoogleMapsOverlay to use the managed projection assembly instead of the unmanaged one? We are using MapSuite Desktop 4.0.40.


We are currently using xcopy deployment, and having the requirement to use the merge module is less than ideal.


Thanks,

Paul



#13

Paul, 
 Thanks for your posts and suggestions. 
  
 I think it would be a good idea to change the projection used in GoogleOverlay from unmanaged projection to managed projection. I would address this to be an issue and discuss this with our manager to get the best way to it. 
  
 Thanks for your ideas. 
  
 Yale 


#14

Paul, 
  
   We are going to move forward with the switch to the managed projection class.  Yale will update you when it is ready and you can get it from the daily builds. 
  
 David

#15

Has support for the managed projection class, been included in GoogleOverlay and the VirtualEarth Overlay, in the new version 4.5 ?? 
  
 We would really like to get rid of the Proj4Extensionx86.dll and the other dlls required to be placed in System32

#16

Tommy,


Thanks for your post and questions.
I am sorry I did not inform you on time that we have get the ManagedProj4Projection class integrated into our products since the latest public release on Nov 1st, also the GoogleOverlay and VirtualEarthOverlay has used the ManagedProj4Projection instead of Proj4Projection internally, so the related projection DLLs in the system32 folder can be removed without any affects when you are using those overlays.
Any more questions please feel free to let me know.
Thanks.
Yale