Loading Xml-File as embedded resource in DLL

C

Christofer Dutz

Hi,


I am trying to read a XML-File which I marked as embedded resource from
within the code of my DLL. Unfortunately it doesn't work.
On my search for the error I inserted some code for outputing all
Resources names to a simple textfile. Here nothing is output.

Here my code (a little messy after about 3 hours of debugging):
// Use the LoadXml method to load the XslTransform
// object with the style sheet.
assembly = Assembly.GetCallingAssembly();

// -- Begin -- Debug code
string[] resourceNames = assembly.GetManifestResourceNames();
System.IO.StreamWriter writer =
System.IO.File.CreateText("c:\\TestFile.txt");
writer.WriteLine("Also ... ich hoffe, dass da jetzt gleich was im
Textfile steht ...");
for(int x = 0; x < resourceNames.Length; x++)
{
writer.WriteLine(resourceNames[x]);
}
writer.WriteLine("... Ende");
writer.Close();
// -- End -- Debug code

// Read the Resource and create an XmlDocument from it
s =
assembly.GetManifestResourceStream("syngo.SeSo.Engine.XPathResolver.xslt");
theStylesheet = new XmlDocument();
reader = new StreamReader(s);
theStylesheet.LoadXml(reader.ReadToEnd());


I have no more ideas ... please help me ...

Christofer
 
S

SP

I am trying to read a XML-File which I marked as embedded resource from
within the code of my DLL. Unfortunately it doesn't work.
On my search for the error I inserted some code for outputing all
Resources names to a simple textfile. Here nothing is output.

Here my code (a little messy after about 3 hours of debugging):
// Use the LoadXml method to load the XslTransform
// object with the style sheet.
assembly = Assembly.GetCallingAssembly();

// -- Begin -- Debug code
string[] resourceNames = assembly.GetManifestResourceNames();
System.IO.StreamWriter writer =
System.IO.File.CreateText("c:\\TestFile.txt");
writer.WriteLine("Also ... ich hoffe, dass da jetzt gleich was im
Textfile steht ...");
for(int x = 0; x < resourceNames.Length; x++)
{
writer.WriteLine(resourceNames[x]);
}
writer.WriteLine("... Ende");
writer.Close();
// -- End -- Debug code

// Read the Resource and create an XmlDocument from it
s =
assembly.GetManifestResourceStream("syngo.SeSo.Engine.XPathResolver.xslt");
theStylesheet = new XmlDocument();
reader = new StreamReader(s);
theStylesheet.LoadXml(reader.ReadToEnd());

You mention resources in a DLL but are using Assembly.GetCallingAssembly.
You should
use Assembly.GetAssembly

e.g.

string[] resourceNames =
Assembly.GetAssembly(typeof(MyDLL.AnyClassInDLL)).GetManifestResourceNames()
;
 
C

Christofer Dutz

SP said:
You mention resources in a DLL but are using Assembly.GetCallingAssembly.
You should
use Assembly.GetAssembly

e.g.

string[] resourceNames =
Assembly.GetAssembly(typeof(MyDLL.AnyClassInDLL)).GetManifestResourceNames()
;

Unfortunately this didn't work. What would exactly be the name if I have
a class a.b.c.d.CoolClass in a dll called myCoolStuff.dll?
I tried simply using the namespace of the class I am trying to read the
Resource with (a.b.c.d.CoolClass) but I can't see any resources :(
As far as I understood the whole resource-thing all Files are accessable
under the projects default namespace and all I have to do is set the
"Build Action" to "Embedded Resource" ... is this correct?

Chris
 
S

SP

You mention resources in a DLL but are using
Assembly.GetCallingAssembly.
You should
use Assembly.GetAssembly

e.g.

string[] resourceNames =
Assembly.GetAssembly(typeof(MyDLL.AnyClassInDLL)).GetManifestResourceNames()
;

Unfortunately this didn't work.

The resourceNames array is empty?

What would exactly be the name if I have
a class a.b.c.d.CoolClass in a dll called myCoolStuff.dll?

What name are you referring to? The name of the resource? Lets get string[]
resourceNames =
Assembly.GetAssembly(typeof(MyDLL.AnyClassInDLL)).GetManifestResourceNames()
working first. Then this will give you the resource name.

SP
 
C

Christofer Dutz

SP said:
You mention resources in a DLL but are using
Assembly.GetCallingAssembly.
You should
use Assembly.GetAssembly

e.g.

string[] resourceNames =
Assembly.GetAssembly(typeof(MyDLL.AnyClassInDLL)).GetManifestResourceNames()

Unfortunately this didn't work.


The resourceNames array is empty?

What would exactly be the name if I have
a class a.b.c.d.CoolClass in a dll called myCoolStuff.dll?


What name are you referring to? The name of the resource? Lets get string[]
resourceNames =
Assembly.GetAssembly(typeof(MyDLL.AnyClassInDLL)).GetManifestResourceNames()
working first. Then this will give you the resource name.

SP

I tried simply using the namespace of the class I am trying to read the
Resource with (a.b.c.d.CoolClass) but I can't see any resources :(
As far as I understood the whole resource-thing all Files are accessable
under the projects default namespace and all I have to do is set the
"Build Action" to "Embedded Resource" ... is this correct?

What I meant was what do I have to put in instead of MyDLL.AnyClassInDLL
Is this jeust the simple namespace of any class within the same DLL? or
do I have to append the dll-name in some way?
 
S

SP

I tried simply using the namespace of the class I am trying to read the
What I meant was what do I have to put in instead of MyDLL.AnyClassInDLL
Is this jeust the simple namespace of any class within the same DLL? or
do I have to append the dll-name in some way?

It can be the name of any class in the DLL that contains the embedded
resources, it needs to be
qualified as if you were instansiating it in the exact same code block, so
it may need
to be fully qualified or might just need the name of the DLL. Your code
won't compile if
typeof(MyDLL) can not be resolved.

SP
 
C

Christofer Dutz

SP said:
It can be the name of any class in the DLL that contains the embedded
resources, it needs to be
qualified as if you were instansiating it in the exact same code block, so
it may need
to be fully qualified or might just need the name of the DLL. Your code
won't compile if
typeof(MyDLL) can not be resolved.

SP

I am building a Project which is compiled into a DLL. The default
namespace of the project is "syngo.SeSo.Engine". I added an XSL-File
called "XPathResolver.xsl" as "embedded resource". This should result in
the file beeing available under the name
"syngo.SeSo.Engine.XPathResolver.xsl". Here is my code:
using System.IO;
using System.Reflection;
using System.Xml;
using System.Xml.Xsl;
using syngo.SeSo.Utilities;

namespace syngo.SeSo.Engine
{
internal class XPathResolver
{
/// <summary>
/// This method is used for eliminating all occurences
/// of relative XPath expressions. I also handles resolving
/// all usages of complex datatypes by calling the
/// DatatypeResolver.
/// </summary>
/// <param name="theDocument">Document containing relative XPath
expressions and complex datatypes</param>
/// <returns>Document containing only absolute XPath expressions and
simple datatypes</returns>
internal static System.Xml.XmlDocument Process(System.Xml.XmlDocument
theDocument)
{
Assembly assembly;
Stream s;
XmlDocument theStylesheet;
StreamReader reader;

// Use the LoadXml method to load the XslTransform
// object with the style sheet.
assembly = Assembly.GetAssembly(typeof(syngo.SeSo.Engine.XPathResolver));

// -- Begin -- Debug code
string[] resourceNames = assembly.GetManifestResourceNames();
System.IO.StreamWriter writer =
System.IO.File.CreateText("c:\\TestFile.txt");
writer.WriteLine("The MainifestResourceNames are: {");
for(int x = 0; x < resourceNames.Length; x++)
{
writer.WriteLine(resourceNames[x]);
}
writer.WriteLine("}");
writer.Close();
// -- End -- Debug code

return null;
}
}
}

The resulting textfile contains not a singe ResourceName.
What am I doing wrong?
 
C

Christofer Dutz

SP said:
It can be the name of any class in the DLL that contains the embedded
resources, it needs to be
qualified as if you were instansiating it in the exact same code block, so
it may need
to be fully qualified or might just need the name of the DLL. Your code
won't compile if
typeof(MyDLL) can not be resolved.

SP
After trying a very long time we switched back to loading simple files,
since wa couldn't get loading from resource to work.

Thanks anyway ...
 
Top