Hi Dave,
Do you mean you have a Word Add-in "AutoTag2007.dll" and a config file
"AutoTag2007.dll.config" in the same directory, and your code in
AutoTag2007.dll uses classes in System.Configuration namespace to read
setting values from the default config file, but you're not sure whether
the code will read from AutoTag2007.dll.config or WinWord.exe.config? If I
misunderstood you, please correct me. And by the way, you may already know
that the COM shim wizard is a tool not supported by Microsoft (see
http://msdn.microsoft.com/en-us/library/bb508939.aspx). But I'm glad to
clarify the config file story for you.
So the "default config file" story should go like this:
* If you are developing a "Shim Wizard Add-in" (which is your case here),
the default config file will depends on whether or not you check the "This
Add-in has a config file" checkbox during the creation of the project. If
you checked it, the default config file will be AutoTag2007.dll.config, if
not, it will be winword.exe.config.
* If you are developing a "Shared Add-in", the default config file will be
Winword.exe.config.
* If you are developing a "VSTO" add-in, the default config file will be
AutoTag2007.dll.
The underlying mechanism for setting the default config file is related to
the AppDomain creation. While a new AppDomain is being created, we can
assign the config file path to the new AppDomain by passing in an instance
of AppDomainSetup class. The ConfigurationFile property of the
AppDomainSetup class specifies the config file path.
A "Shared Add-in" cannot control how its AppDomain is being created, the
default config file will be the host application's EXE file name plus
".config".
A "VSTO Add-in" runs in its own AppDomain created by the VSTO runtime, and
the runtime always sets the config file path to the Add-in assembly's DLL
file name plus ".config".
A "Shim Wizard Add-in" gave you the option to make the choice whether or
not to set the config file path. Let's take a look at the source code of
the shim:
In the CreateAggregatedAddIn method, there is a line which creates the
AppDomain for the add-in:
// CreateInstance: loads the CLR, creates an AppDomain, and creates an
// aggregated instance of the target managed add-in in that AppDomain.
HRESULT CCLRLoader::CreateAggregatedAddIn(
IUnknown* pOuter,
LPCWSTR szAssemblyName,
LPCWSTR szClassName,
LPCWSTR szAssemblyConfigName)
{
...
// Load the CLR, and create an AppDomain for the target assembly.
IfFailGo( LoadCLR() );
IfFailGo( CreateAppDomain(szAssemblyConfigName) ); // <--
here, it passes in the config file name
...
}
And we can see how the config file name is used in CreateAppDomain method:
// In order to securely load an assembly, its fully qualified strong name
// and not the filename must be used. To do that, the target AppDomain's
// base directory needs to point to the directory where the assembly is.
HRESULT CCLRLoader::CreateAppDomain(LPCWSTR szAssemblyConfigName)
{
USES_CONVERSION;
HRESULT hr = S_OK;
// Ensure the AppDomain is created only once.
if (m_pAppDomain != NULL)
{
return hr;
}
CComPtr<IUnknown> pUnkDomainSetup;
CComPtr<IAppDomainSetup> pDomainSetup;
CComPtr<IUnknown> pUnkAppDomain;
TCHAR szDirectory[MAX_PATH + 1];
TCHAR szAssemblyConfigPath[MAX_PATH + 1];
CComBSTR cbstrAssemblyConfigPath;
// Create an AppDomainSetup with the base directory pointing to the
// location of the managed DLL. We assume that the target assembly
// is located in the same directory.
IfFailGo( m_pCorRuntimeHost->CreateDomainSetup(&pUnkDomainSetup) );
IfFailGo( pUnkDomainSetup->QueryInterface(
__uuidof(pDomainSetup), (LPVOID*)&pDomainSetup) );
// Get the location of the hosting shim DLL, and configure the
// AppDomain to search for assemblies in this location.
IfFailGo( GetDllDirectory(
szDirectory, sizeof(szDirectory)/sizeof(szDirectory[0])) );
pDomainSetup->put_ApplicationBase(CComBSTR(szDirectory));
// Set the AppDomain to use a local DLL config if there is one.
IfFailGo( StringCchCopy(
szAssemblyConfigPath,
sizeof(szAssemblyConfigPath)/sizeof(szAssemblyConfigPath[0]),
szDirectory) );
if (!PathAppend(szAssemblyConfigPath, szAssemblyConfigName))
{
hr = E_UNEXPECTED;
goto Error;
}
IfFailGo( cbstrAssemblyConfigPath.Append(szAssemblyConfigPath) );
IfFailGo( pDomainSetup->put_ConfigurationFile(cbstrAssemblyConfigPath)
);
// Create an AppDomain that will run the managed assembly, and get the
// AppDomain's _AppDomain pointer from its IUnknown pointer.
IfFailGo( m_pCorRuntimeHost->CreateDomainEx(T2W(szDirectory),
pUnkDomainSetup, 0, &pUnkAppDomain) );
IfFailGo( pUnkAppDomain->QueryInterface(
__uuidof(m_pAppDomain), (LPVOID*)&m_pAppDomain) );
Error:
return hr;
}
So even you didn't check the "Add-in has a config file" in the Wizard
window, you can still make changes to the shim source to set the default
config file.
If you set the default config file to AutoTag2007.dll.config and you want
to read some settings from winword.exe.config, you can use
ConfigurationManager.OpenExeConfiguration method to do that.
The configuration file needn't be there, neither do the settings. You will
get null references if they're not there, so check for null references will
do it.
Hope this will make things clear.
If you have any further questions regarding this issue, please feel free to
post here.
Regards,
Jie Wang (
[email protected], remove 'online.')
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.
Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
