The following are line 72 and 73 of TestSystem.vb:
---
Dim config As NameValueCollection =
CType(System.Configuration.ConfigurationSettings.GetConfig("appSettings"),
NameValueCollection)
Assertion.Assert("No config file."
I'll offer one counter point of view to using NAnt from COM. I had started,
but lost the motivation to complete, a task to have NAnt tasks callable from a
DTS package. It's entirely possible that building this functionality would
require no COM visibility, ie the implementation just has the name
It works both ways. If you feel that there is no demand for using NAnt
from COM then there is no need to specifically allow or dissallow access.
We don't mark them COM visible right now - we just don't mark them
invisible. This seems like a non issue to me.
My view of the com visible attribute i
Arjen,
Until now, I've always used the XsdTask (from NantContrib) to generate my
typed datasets from xml schemas. I've found that using this this task has
several disadvantages:
* You can't use filesets to generate datasets from a collections of xml schemas.
Since my entire build environment is
My post was not about having a solution for a problem, I just think it's
best to have a clear message about what we support and what we don't support
...
And not explicitly marking an assembly as being COM visible or not just
leaves users in the dark as to if using NAnt through COM is supported or
Hi,
Until now, I've always used the XsdTask (from NantContrib) to generate my
typed datasets from xml schemas. I've found that using this this task has
several disadvantages:
* You can't use filesets to generate datasets from a collections of xml schemas.
Since my entire build environment is bas
