The Xcopy config script makes an assumption that you will keep the existing unzipped structure and place your *.ora files under the "\network\admin" directory. That's the default behavior. You may use a different location, but you need to modify the configuration script accordingly. Basically, any customized setup, you will need to modify the configuration script in some way.
The thinking behind the xcopy install is small, unattended, and flexible configuration. With the GUI installer, the installer will set up automatically any of the most common customization choices.
But I did keep the directory structure as far as the network\admin directory is concerned. The only change I made was to the ODP.Net directory that is in the same directory as the network directory. I changed it to v121010. So under C:\Oracle I have
* This is where our sql.ora and tnsnames.ora file are located and we have the TNS_Admin environmental pointing to this directory.
v121010 (originally ODP.Net, changed to accommodate future versions being installed side-by-side)
So the change I made to the ODP.Net directory name should not affect the path to the network\admin directory.
<setting name="tns_admin" value="c:\oracle\odp.net\v121010\managed\x64\..\..\..\network\admin" />
And to prove this I did an install using the default directories (still under C:\Oracle) and the setting value still is not a valid directory location.
<setting name="tns_admin" value="c:\oracle\odp.net\odp.net\managed\x64\..\..\..\network\admin" />
This looks to me like the configuration.bat is trying to get the default path by:
* Starting at the path where the driver is installed ------------ c:\oracle\odp.net\odp.net\managed\x64"
* Then goinging back 3 directories (..\..\..\network\admin) -- c:\Oracle\odp.net\network\admin (which is what I thought it should be set to)
I think the value being set is suppose to be the physical directory, but instead it is concatenating 2 string together that are used to "dynamically" get the physical path to the network\admin directory. I honestly think this is a bug in the configuration.bat.
I tested with the "c:\oracle\odp.net\odp.net\managed\x64\..\..\..\network\admin" and with "c:\oracle\odp.net\network\admin". Both work fine to allow ODP.NET to find its *.ora files. Both formats are valid.
If you prefer one over the other, you can modify the batch file or the post-install output as you'd like, but this is not a bug.
So I guess I am still not sure why the windows client application gets TNS error, but after adding TNS_Admin environmental variable the application works fine. Is the machine.config use for windows client applications, or only web based applications? Is there a setting in the application config that tell the application to use the setting in the machine.config?
Not that big of deal, since it is probably better for us to set the setting the in TNS_Names environmental variable for our IIS Servers. Just wondering why the application does not work without the environmental variable set.
Ah, the fact that TNS_ADMIN in machine.config is not recognized may be a bug. I can't explain why the machine.config setting isn't used by managed ODP.NET. It should be.
machine.config is used for all .NET applications. app.config is used in higher precedence than machine.config.
If you want to investigate further, can you test the TNS_ADMIN directory in you web.config or app.config? How about if you use the <dataSource> setting for your connect descriptor instead? The latter overrides the former FYI if you try to set both.
<!-- <dataSource alias="orcl" descriptor="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME = orcl)))"/> -->
<!-- <setting name="TNS_ADMIN" value="C:\dir1\dir2\"/> -->
Let me ask something, are you installing into a 32-bit or 64-bit .NET Framework? Is your application running in the 32-bit or 64-bit .NET Framework?
A likely reason that the TNS_ADMIN environment variable works, but not the .NET config settings is that you've run the 32-bit configure.bat script, but your app is running in 64-bit .NET Framework, or vice versa. You can tell what bitness the script is by which directory it's located in upon unzipping.
The application is running on a 64-bit machine and I ran the configuration.bat for the 64-bit driver, so pretty sure that is not it. I will try to test some of the things you mentioned earlier in this post by the end of this week and post what I find out here.
Verify that you're using the 64-bit .NET Framework, not the 32-bit .NET Framework. The OS may be 64-bit, but it's possible to run 32-bit .NET Framework on a 64-bit OS.
In your C:\Windows\Microsoft.NET\ directory, there are two subdirectories, one for 32-bit (Framework) and one for 64-bit (Framework64). Each has its own machine.config depending on the bitness of the .NET Framework you use.