THREADS - ESRI Discussion Forums

You are here: Home > User Forums > arcgis desktop discussion forums > Thread Replies

ArcGIS Desktop Discussion Forums

ArcGIS Desktop - ArcObjects General forum

.Net deployment and stdole.dll	bob grabhorn	Mar 14, 2005
Re: .Net deployment and stdole.dll	Neil Clemmons	Mar 15, 2005
Re: .Net deployment and stdole.dll	bob grabhorn	Mar 15, 2005
Re: .Net deployment and stdole.dll	Neil Clemmons	Mar 15, 2005
Re: .Net deployment and stdole.dll	bob grabhorn	Mar 15, 2005
Re: .Net deployment and stdole.dll	bob grabhorn	Mar 15, 2005
Re: .Net deployment and stdole.dll	Neil Clemmons	Mar 16, 2005
Re: .Net deployment and stdole.dll	bob grabhorn	Mar 16, 2005
Re: .Net deployment and stdole.dll	Neil Clemmons	Mar 16, 2005
Re: .Net deployment and stdole.dll	bob grabhorn	Mar 16, 2005
Re: .Net deployment and stdole.dll	bob grabhorn	Mar 16, 2005
Maybe getting somewhere	bob grabhorn	Mar 16, 2005
Re: Maybe getting somewhere	Neil Clemmons	Mar 17, 2005
Re: Maybe getting somewhere	Eli Tiffin	Jun 02, 2005
Re: Maybe getting somewhere	Craig Carpenter	Nov 17, 2005
Never did figure it out	bob grabhorn	Nov 21, 2005
Re: .Net deployment and stdole.dll	Shea Burns	Apr 18, 2006
Re: .Net deployment and stdole.dll	Jacquelyn Bilbro	Jan 10, 2007

Report Inappropriate Content • Top • Print • Reply
Subject	.Net deployment and stdole.dll
Author	bob grabhorn
Date	Mar 14, 2005
Message	Hello, all. We're working on the deployment of our first .Net/ArcObjects application. We've read and followed the advice about building the installers and had good success except with stdole.dll. As advised, we've excluded it from the list of dependencies. But then, on most test target machines, we get messages saying: "...FileNotFoundException: File or assembly name stdole, or one of its dependencies..." On my (developer) machine, there is an stdole assembly in the GAC. But where does it need to be on the target machines, and how does it get there if our installer doesn't include it? Many thanks for any help.
	Bob Grabhorn JBS International

Report Inappropriate Content • Top • Print • Reply
Subject	Re: .Net deployment and stdole.dll
Author	Neil Clemmons
Date	Mar 15, 2005
Message	Your installer should put it in the GAC if it's not already there. Unlike the COM dlls the ArcObjects library is composed of, .NET dlls are not subject to the "dll hell" situation of the past. Multiple versions of the same dll can exist on the same computer in the .NET world. The advice from the ESRI instructions to remove the ESRI assemblies is good, but they should have done a better job explaining what you really need to do. The target computer must have the .NET Framework, the ESRI assemblies, and any other dependencies (like stdole) installed before your app can run. The ideal place to put things is in the GAC because it's a common location and prevents multiple copies of the same dlls from being copied to the machine. The dll must have a strong name before you can put it in the GAC (the ESRI dlls have strong names). You can also simply copy all files to the application directory, but this tends to result in multiple copies of the same dlls on the target computer. It doesn't affect anything, as the applications will use the copy of the dll in their own locations, but it's a waste of disk space.
	Neil Clemmons Senior GIS Developer Geographic Information Services, Inc. Birmingham, AL http://www.gis-services.com Check out our blog: http://blog.gis-services.com/

Report Inappropriate Content • Top • Print • Reply
Subject	Re: .Net deployment and stdole.dll
Author	bob grabhorn
Date	Mar 15, 2005
Message	Thanks, Neil. So, is the best way put stdole into the GAC to grab its assembly on my machine and add it to the target machine GAC folder using the same steps outlined for the ESRI assemblies in your ".NET Application Installation Procedure" document? Many thanks,
	Bob Grabhorn JBS International

Report Inappropriate Content • Top • Print • Reply
Subject	Re: .Net deployment and stdole.dll
Author	Neil Clemmons
Date	Mar 15, 2005
Message	That's how I would do it. Give it a try on a few differently configured machines and see if you run into any problems. I don't think you will, but you never know.
	Neil Clemmons Senior GIS Developer Geographic Information Services, Inc. Birmingham, AL http://www.gis-services.com Check out our blog: http://blog.gis-services.com/

Report Inappropriate Content • Top • Print • Reply
Subject	Re: .Net deployment and stdole.dll
Author	bob grabhorn
Date	Mar 15, 2005
Message	Great. Thank you. We'll try it out on some test machines and see what happens. We have both Win2k and XP machines. Do you anticipate any problems there? I'll come back and give you a star if all goes well. Thanks,
	Bob Grabhorn JBS International

Report Inappropriate Content • Top • Print • Reply
Subject	Re: .Net deployment and stdole.dll
Author	bob grabhorn
Date	Mar 15, 2005
Message	Well... I followed everything down to the letter, I think. Even started over and did it a second time. It installs the Framework beautifully, but then I get "Unable to get installer types in the assembly. --> One or more of the types in the assembly unable to load." I take that to mean that the ESRI assemblies aren't loading. It's surprising to me that the MSI is only 3MB. I'd think that it'd be considerably larger if it were carrying all of the ESRI assemblies, too. I'm betting I'm missing something fairly obvious, but boy I don't see it. Any ideas? Thanks,
	Bob Grabhorn JBS International

Report Inappropriate Content • Top • Print • Reply
Subject	Re: .Net deployment and stdole.dll
Author	Neil Clemmons
Date	Mar 16, 2005
Message	I've run into this issue recently and it turned out to be the new service pack for ArcGIS. The dll versions for the ESRI assemblies are different. After making sure the assemblies that I was installing matched the version under which my application was compiled, the error went away. To do this, I looked at the properties of each ESRI dll in the installer project. It had grabbed several of them from the GAC on my computer. I changed it to get all of them from the DotNet folder under my ArcGIS installation, since the version in the GAC was from a previous installer test and was not the current version.
	Neil Clemmons Senior GIS Developer Geographic Information Services, Inc. Birmingham, AL http://www.gis-services.com Check out our blog: http://blog.gis-services.com/

Report Inappropriate Content • Top • Print • Reply
Subject	Re: .Net deployment and stdole.dll
Author	bob grabhorn
Date	Mar 16, 2005
Message	The version discrepancy was a good tip. Here's what I've found: The installer runs successfully on a target machine if and only if the ESRI assemblies are in the dotNet folder AND have already been registered with the GAC. Now, my understanding so far has been that registering the assemblies with the GAC could only happen if the .Net Framework 1.1 has been installed. We can't assume that, which is why we're adopting the bootstrapper approach. If we know we may need to install the Framework first, then we also know we'll need to register the ESRI assemblies with the GAC. I'm not sure if it's a timing issue, or what the problem is. Any thoughts? Thanks again,
	Bob Grabhorn JBS International

Report Inappropriate Content • Top • Print • Reply
Subject	Re: .Net deployment and stdole.dll
Author	Neil Clemmons
Date	Mar 16, 2005
Message	So far, I haven't run into any issues other than the ESRI assembly version difference related to Service Pack 2. However, I wonder if the problem stems from some of the ESRI assemblies not registering because they depend on stdole. You might look into seeing if you can install and register stdole in the GAC before the ESRI assemblies get installed and see if that helps any. In theory, the target computer should only need the ESRI assemblies in the GAC.
	Neil Clemmons Senior GIS Developer Geographic Information Services, Inc. Birmingham, AL http://www.gis-services.com Check out our blog: http://blog.gis-services.com/

Report Inappropriate Content • Top • Print • Reply
Subject	Re: .Net deployment and stdole.dll
Author	bob grabhorn
Date	Mar 16, 2005
Message	Okay. I'll give that a try, too. I should probably have mentioned a while back that I still have other remaining dependencies. They are: AxInterop.SHDocVw.dll MyOtherProject.dll (has ESRI dependencies) AnotherCustomDLL.dll (no ESRI dependencies) InteropSHDocVw.dll stdole.dll I've excluded stdole.dll and shdocvw.dll in the list of dependencies. I'm including the others, though. stdole is now one of the assemblies in the Target Machine GAC Folder along with the ESRI assemblies, but nothing else. Oh, and what about those policy... ESRI assemblies? Do those need to come along, too? What are they? I'll experiment a bit more.
	Bob Grabhorn JBS International

Report Inappropriate Content • Top • Print • Reply
Subject	Re: .Net deployment and stdole.dll
Author	bob grabhorn
Date	Mar 16, 2005
Message	No luck there, either. After the successful install following the "pre-installation" of the ESRI assemblies, I left stdole in the GAC and tried an install of everything, including the ESRI assemblies but not stdole. It still wouldn't go.
	Bob Grabhorn JBS International

Report Inappropriate Content • Top • Print • Reply
Subject	Maybe getting somewhere
Author	bob grabhorn
Date	Mar 16, 2005
Message	I discovered that my dependencies include two copies of both ESRI.ArcGIS.System and ESRI.ArcGIS.SystemUI. The reason for that is that my version of ESRI.ArcGIS.Utility is 535 instead of 560 like everything else. I reinstalled SP2 from the ESRI web site, and I still don't have a 560 version of Utility. But I'm not the only person to have this problem: http://forums.esri.com/Thread.asp?c=93&f=982&t=150095&mc=0 Has anyone else seen this or, better yet, solved it? The Utility assembly is required for the COM Registration functions. I'd think lots of folks would be running into this. Thanks,
	Bob Grabhorn JBS International

Report Inappropriate Content • Top • Print • Reply
Subject	Re: Maybe getting somewhere
Author	Neil Clemmons
Date	Mar 17, 2005
Message	I have version 535 of the Utility dll on my machine as well. Try installing all of the ESRI dlls, your application dll(s), and all other dependencies to the same install directory and see if that makes the problem go away. It should since the application directory is the first place a needed dll is expected to be. You may also want to place a call to tech support and see if they have any ideas. Let me know if you find out anything.
	Neil Clemmons Senior GIS Developer Geographic Information Services, Inc. Birmingham, AL http://www.gis-services.com Check out our blog: http://blog.gis-services.com/

Report Inappropriate Content • Top • Print • Reply
Subject	Re: Maybe getting somewhere
Author	Eli Tiffin
Date	Jun 02, 2005
Message	Here's what I've come up with to deal with my application deployment issues. I never include ESRI assemblies in my install package. They should already be on the target machine by the time your application is installed. I typically include the stdole assembly when it's required. Something to do with fonts (ie. annotation and labels) requires that the Microsoft primary interop assembly is installed in the GAC. My guess is that ESRI's assemblies, probably Carto and some others were built against the stdole assembly. It's safest to just go ahead and have your install package ensure that it is in the GAC. I like to include the Microsoft redistributable .Net Framework package with my installers. It saves the client the trouble of downloading it. I've found that versioning issues are easiest to deal with if I don't have any ESRI service packs installed on the development/build machine. By doing this, my assemblies are more or less ensured forward compatibility with the 9.0 series ESRI assemblies. Unfortunately, once you've installed a service pack, the only way to remove it is to uninstall and reinstall ArcGIS from the source disk. The reason this method works is that with each service pack ESRI releases, new assembly binding policies are added to the GAC that enforce usage of the newest versions of the assemblies. Since my assemblies are built against the original published versions of ESRI's ArcObjects assemblies, they will in turn be redirected by the binding policies to the newest versions. If you build your assemblies against a service pack version, that service pack or higher will be required on any target machines for your application, a feature that is not alway guaranteed. You may be able to keep the service packs on your development machine if you know how to setup your own compiler scripts to bind your assemblies to specific versions of ESRI's (haven't tried it yet). Research .config files and binding redirect for more ideas on how to customize version binding. When installing on the target machine, certain prerequisites must be met: 1. Must have .NET Framework installed (duh!) Do this first. 2. Must have ESRI's ArcObjects primary interop assemblies installed. I have a feeling this is where some people go wrong. The client should insert thier ArcGIS 9.0 disk and either install ArcGIS for the first time or to modify the existing installation. Go into the customize installation and ensure that .Net options are included for installation. These options will not be available if .NET Framework is not installed (goto step 1). If Framework was not present during original installation, .Net support was not installed. Also, if .Net support wasn't installed, it won't be corrected by simply installing a ArcGIS service pack, I've tried it. 3. Install or reinstall the latest ESRI service packs. Even if you have already installed them, if the .NET support was not installed at that time, it now needs the service pack again.(jeez, this can take a long time!) 4. Check the GAC, make sure that the ESRI primary interop assemblies are present. If you've installed service packs, you will have multiple of each assembly with different version numbers as well as binding redirect policies. 5. If everything went OK, you should be in good shape to install your application. I hope all this info helps, let me know if you find less time consuming methods to get everything to work.
	Eli Tiffin Research & Development Bruce Harris & Associates, Inc

Report Inappropriate Content • Top • Print • Reply
Subject	Re: Maybe getting somewhere
Author	Craig Carpenter
Date	Nov 17, 2005
Message	Bob or Neil Did you guys ever work out how to distribute the ESRI .Net Assemblies in a VS2003 setup file to appropriately setup a client machine that doesn't have any of the ESRI.Net Assemblies i.e. install and register in the \ArcGIS\DotNet folder and the GAC Folder? Thus avoiding that horrible error message "One or more of the types in the assembly unable to load" Also did you guys come across any information regarding the esri policy assemblies and what they do, if they are required e.t.c? I'm currently trying to bundle all of the setup requirements into a one step setup file. Thus avoiding the client having to reinstall Arc GIS software to install esri .net assemblies. Setup Requirements: 1)Install .Net Framework if required 2)Install & Register Esri .Net Assemblies in the appropriate areas (\ArcGIS\DotNet\ & GAC) 3)Install & Register Custom Tool Regards Craig Carpenter GIS Analyst

Report Inappropriate Content • Top • Print • Reply
Subject	Never did figure it out
Author	bob grabhorn
Date	Nov 21, 2005
Message	Hi, Craig. We tried everything we could think of but never managed to bundle everything into one install. Like you, we didn't want clients to be inserting discs to install ArcGIS or PIAs. So, as I recall, our installation folks ended up sequencing separate installers for your numbers 1, 2, & 3. The stdole.dll was bundled with the custom tool. The policy assemblies provide versioning redirection so that the newest versions are used when appropriate. I wish we'd been able to put it all together in one install, but there just didn't seem to be a way to do that. Best wishes,
	Bob Grabhorn JBS International

Report Inappropriate Content • Top • Print • Reply
Subject	Re: .Net deployment and stdole.dll
Author	Shea Burns
Date	Apr 18, 2006
Message	Hi Neil, I added all the ESRI assemblies to the GAC folder in the File System tab by selecting the assemblies installed in the Program Files\ArcGIS\DotNet folder, but it automatically adds duplicates of some of the assemblies with a source path pointing toward my GAC. I can't seem to delete these either unless I delete the ones with a source path of Program Files\ArcGIS\DotNet first. Did you get any behaviour like this when adding either Files or Assemblies to the GAC folder in the File System tab? If not, any suggestions about what to do about it? Thanks Shea

Report Inappropriate Content • Top • Print • Reply
Subject	Re: .Net deployment and stdole.dll
Author	Jacquelyn Bilbro
Date	Jan 10, 2007
Message	Neil, I am new to ArcObjects programming. Can you tell me how to get a copy of your ".NET Application Installation Procedure" document everyone keeps referring to? Thanks.