Greetings,
We are attempting a remote EnterpriseServices host setup on our network, but cannot seem to get the client install (generated msi from component services on the host machine) to install successfully. Our environment appears as follows:
Web Server (IIS 7.0) - PTWeb
Application Server (2003 SP1) - EnterpriseServicesHostcs
Client (XP SP2) - IE7
We can get the EnterpriseServicesHostcs installed properly (via regsvcs) on the Application Server, and export the pre-built application into an MSI. However, when we go to install the application onto the web server, it complains that it could not register the COM component due to the fact that it cannot find a reference to CSLA. Just for the sake of it, we have also attempted the following, but with little to no success:
We have verified that all of the proper COM settings exist on the application server prior to exporting the MSI. There were thoughts that we should regsiter the CSLA assembly on the web server, however the buildCSLA documentation strongly advises against it. I am certain we are missing some simple detail, but until now it has elluded us. For the record, we have successfully completed this setup on a single location (the web server), and have successfully deployed a proof of concept EnterpriseService in this environment to elimate the environment as an instigator.
Thanks in advance.
Hello there again,
We are still struggling with this issue, and I simply wanted to throw this back out there to see if anyone has had any luck or has any ideas we can try.
Thanks in advance.
OK, for those who are interested, read on...
In order to successfully install a pre-built COM+ proxy (creating this is described on page 618 of Rocky's Expert C# 2005 Business Objects book), you must ensure that the CSLA assembly exists in the system32 directory (e.g. C:\Windows\System32) on the destination system BEFORE you attempt to install the MSI. If you try to install the MSI before hand, COM+ registation will complain that it cannot find the CSLA dependency.
Once installed, you will need to ensure that the account you configured the COM+ server to run in (page 617), is the same account that is used for the application pool of the web site that will access the component (or another account that has access to every tier), otherwise you will get access violations.
More information on troubleshooting EnterpriseService components regarding dependencies can be found here: http://support.microsoft.com/kb/308940.
Best of luck.
Well, your problem is most likely that the account that the application is running under (e.g. Network Service) does not have the appropriate permissions on the app server (hence the access violation comment above). If this is the case, and the application is a web site, you have a couple of options:
1) Create a new application pool on the web server just for this particular web application, assign the application pool to the web site, and assign a specific user for the application pool to run under - if you are in a domain, this should be a domain user with access to every tier; if you don't have a domain, setting the username and password to be the same on all tiers should do the trick.
2) Enable impersonation in the web.config via the <identity .../> tag. Again, this account is going to have to have access to all of the tiers. This would allow you to either impersonate the logged in user (windows authentication), or specify a specific user to impersonate (not really recommended for production).
If the application is not a web site...well...give the user the application is running under permissions to access the app server...;)
If neither of these is the case, post some more information and we will see...
Cheers.
Ben Noyce
I thought I would add one other possibility to an 'Access Denied' error - if you have set all of the permissions up properly and still get access violations, it could be that one of the assemblies containing a business object that is attempting to move through the framework was not installed / successfully referenced from the enterprise service component. You need to be certain that all assemblies that contain business objects to be used by the framework (an any of their dependant assemblies) are installed with the component (and most likely should be located in the same directory). As a best practice, you should probably re-export the proxy and re-install it wherever relevant after registering the new component package.
Best of luck.
You're first post solved that problem. Thanks so much Ben. I did run into more issues, and the other posts helped solve the rest. Again thanks.
For those who may be having a similar issue, the server was orginally setup and I had installed remoting, and web services. But someone promoted it to a domain controller and everything that worked stopped.
Reinstalling SQL 2005 under the new user fixed this problem.
I'm now having more issues with Enterprise services. Where it worked before (after being promoted to a domain controller), it does not work now.
I've followed all the steps of reinstalling the com objects, yet it will not recognize that the file exists. Everything works except through Enterprise.
The first curious thing I noticed is when I reinstalled the com objects, it remembered the username and the App root directory. I think this may be causing the problem, as the old dlls were deleted and a fresh batch was recomplied and rebuilt. If you look at the error msg, there are two locations. the one with 'Transfer\Ted' is incorrect. I don't understand why COM is still looking for it there, even when I added the files from the 'Test' directory.
Also, I'm running the PTWin right from the server to make sure it sets up the right proxy calls. I did this test for all other types before testing on a client machine. Failure is on the server not the client.
Thanks.
************** Exception Text **************
System.IO.FileNotFoundException: Could not load file or assembly 'EnterpriseServicesHostcs' or one of its dependencies. The system cannot find the file specified.
File name: 'EnterpriseServicesHostcs'
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Activator.CreateInstance(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityInfo, StackCrawlMark& stackMark)
at System.Activator.CreateInstance(String assemblyName, String typeName)
at Csla.DataPortal.GetDataPortalProxy(Boolean forceLocal) in D:\Transfer\Ted\projects\csla20cs\csla20cs\Csla\DataPortal\Client\DataPortal.cs:line 410
at Csla.DataPortal.Fetch(Type objectType, Object criteria) in D:\Transfer\Ted\projects\csla20cs\csla20cs\Csla\DataPortal\Client\DataPortal.cs:line 175
at Csla.DataPortal.Fetch[T](Object criteria) in D:\Transfer\Ted\projects\csla20cs\csla20cs\Csla\DataPortal\Client\DataPortal.cs:line 140
at ProjectTracker.Library.Security.PTIdentity.GetIdentity(String username, String password) in D:\Test\csla20cs\ProjectTracker20cs\ProjectTracker.Library\Security\PTIdentity.cs:line 57
at ProjectTracker.Library.Security.PTPrincipal.Login(String username, String password) in D:\Test\csla20cs\ProjectTracker20cs\ProjectTracker.Library\Security\PTPrincipal.cs:line 15
at PTWin.LoginForm.OK_Click(Object sender, EventArgs e) in D:\Test\csla20cs\ProjectTracker20cs\PTWin\LoginForm.cs:line 23
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.PerformClick()
at System.Windows.Forms.Form.ProcessDialogKey(Keys keyData)
at System.Windows.Forms.TextBoxBase.ProcessDialogKey(Keys keyData)
at System.Windows.Forms.Control.PreProcessMessage(Message& msg)
at System.Windows.Forms.Control.PreProcessControlMessageInternal(Control target, Message& msg)
at System.Windows.Forms.Application.ThreadContext.PreTranslateMessage(MSG& msg)
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
PTWin
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///D:/Test/csla20cs/ProjectTracker20cs/PTWin/bin/Debug/PTWin.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Csla
Assembly Version: 2.1.1.0
Win32 Version: 1.0.0.0
CodeBase: file:///D:/Test/csla20cs/ProjectTracker20cs/PTWin/bin/Debug/Csla.DLL
----------------------------------------
ProjectTracker.Library
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///D:/Test/csla20cs/ProjectTracker20cs/PTWin/bin/Debug/ProjectTracker.Library.DLL
----------------------------------------
System.Web
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.62 (QFE.060727-6200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.Web/2.0.0.0__b03f5f7f11d50a3a/System.Web.dll
----------------------------------------
From the sounds of it, I would manually uninstall the server component (via revsvcs /u <component> - and you might also check for any orphan enterpriseserviceshostcs.tlb after uninstalling), re-install the server component, re-export the proxy, uninstall the proxy from the clients and re-install. I know the default behavior of Enterprise Services is to re-use a registration if it already exists, which may explain why it remembered the user but not the app directory. Also, and I know you stated this was a server failure, but have you checked to be sure the Csla assembly is in the System32 directory of the CLIENT (where you are installing the proxy)?...this is the EXACT error I received from my original post, and installing the Csla assembly into System32 and re-installing the proxy solved the issue.
Of course a classic Windows reboot never hurt the testing either...
Copyright (c) Marimer LLC