In the January version, if the "bin","debug" was in application path, I remove them, which is bad.
I have change this between the jan release and now (don't remember when)
 
The problem is with Asp.Net and Windows application folder and not with iBATIS
 
In an Asp.NET project the application root is the wwwroot and for a console/windows the application root is
the bin/debug or bin/release
if your project is organized as
AspNetProject
      /bin
      /Resources/Query
     /sqlMap.config
 
ConsoleprojectRoot
      /bin/debug/sqlMap.config
      /Resources/Query
So, if you want to use the same access to your mapping file, you must define a $environ$ variable
and use resource="$environ$/Resources/Query/properties.xml"
with $environ$="" for Asp.NET
and $environ$="/bin/debug" for testing
 
Hope was clear.
 
On 5/26/05, Ted Husted <[EMAIL PROTECTED]> wrote:
Speaking of the configuration files, I just updated to the last
nightly build from the January release, and my configs aren't loading
anymore. :(

----

----> IBatisNet.Common.Exceptions.ConfigurationException : Unable to
load file via resource "/Resources/Query/properties.xml" as resource.
Cause : Could not find a part of the path
"C:\Resources\Query\properties.xml".
----> System.IO.DirectoryNotFoundException : Could not find a part
of the path "C:\Resources\Query\properties.xml".

----

We had defined resource="/ ... " to mean the respective project root,
which varies between web projects and other types.

Are we using a different syntax now?

We're trying to keep our XML resoruce files in "project" relative
locations, rather than relative to wherever .NET wants to hide the
binaries :)

My major configruation problem, and we run into the same problem with
Spring.NET, is that

* my team is test-driven
* we need to use the same configuration files in test and web projects

As a result, file-relative paths are usually not useful, since
"relative" is relative to the project type. The path starts one place
for web projects, and in another place for other projects.

Because of this, we are not able to use a typical Spring.net
configuration. We have to use our own singleton to load the
configuration for the test projects. (Using code I cribbed from
iBATIS.)

IMHO, the two most important things about these configurations are

* A consistent location that can be used with any project type,
library, web, or win project
* Being able to *not* keep original files under bin/Debug for any type
of project

-Ted.

Reply via email to