|
|
Ok, from your first post, I thought somebody is giving you XML that you have to read in. Now I see it is fully under your control. So I must ask: why do you want to use XML? Don't just use it because you *think* you are supposed to. Use it when its *APPROPRIATE*. It often isn't the right choice. People just think they are supposed to use it.
1) do you need it human readable?
2) do you need it human editable?
Before you answer those two questions, let me clarify... say you want to store application settings in an XML file? Your first answer might be "yeah, I want it totally human readable / editable". Why? Do you really want people going in and mucking around with your data files? Are you going to handle all the cases when it gets misformatted by a human? etc?
Now lets get to the real questions:
3) do you need platform interoparability?
4) is data size a concern? is performance? Remember, once your file grows to any reasonable size, xml becomes REALLY slow. At around 200k, it starts to slow down. At around 500k its quite noticable. At around 1MB, its 3 to 4 seconds of load time.
So, anyways, if you don't care about the human aspect and you don't need platform interoparability then XML is must definitely NOT the right choice. Especially if #4 is a concern.
Your best bet then would be binary serialization which is built into .NET as soon as you add the [Serializable] attribute to your class.
|
|
|
|
|
The only reason I thought of XML is because I want an easy way to store the data with the app. Their won't be that much data, and I probably don't want the user screwing with it, so I guess serialization is the best approach.
Everything makes sense in someone's mind
|
|
|
|
|
If you don't want the user to mess with it, then make it Binary. If the user sees something in "English", they might just be tempted to edit it with disastrous results.
|
|
|
|
|
Make it binary
Meaning encrypt it somehow? How would you make it binary?
Everything makes sense in someone's mind
|
|
|
|
|
Write it out using the Binary serialisation formatter. Effectively your code would look something like this:
private void SerializeMyClass<T>(string file, T obj)
{
using (FileStream fs = new FileStream(file, FileMode.Create, FileAccess.Write, FileShare.Write))
{
new BinaryFormatter().Serialize(fs, obj);
}
}
private T Deserialize<T>(string file)
{
using (FileStream fs = new FileStream(file, FileMode.Open, FileAccess.Read, FileShare.Read))
{
IFormatter formatter = new BinaryFormatter();
return (T)formatter.Deserialize(fs, obj);
}
}
|
|
|
|
|
Ok, I see. Thanks
Everything makes sense in someone's mind
|
|
|
|
|
Pete O'Hanlon wrote:
If you don't want the user to mess with it, then make it Binary. If the user sees something in "English", they might just be tempted to edit it with disastrous results.
LOL!!
At a previous company where I worked at, I was "second in command" on my team and the lead *insisted* on using XML so it was human readable. I argued with him for quite a while about it before giving up and moving on with my life.
Fast forward 2yrs later when we finally shipped. Apperently users were screwing around with the XML files and causing issues like circumventing security, etc. So his solution was to just assign strict ownership of the XML file to the windows service so nobody else could touch it (apperently not realizing that anybody with admin rights could reassign ownership).
Oh well... at least I don't work there anymore.
|
|
|
|
|
There have been some great answers here, especially challenging you to think about whether or not you need to use XML at all. If you do, however, then you should have a schema designed to back up your XML - and if you do, you can use the .NET command xsd.exe[^] to generate a class structure that maps to your XML (and thus, your XML hierarchy).
|
|
|
|
|
Ugh... xsd.exe... double ugh.
As an example, here is a simple XML file:
<head>
<items>
<item Name="Item1" />
<item Name="Item2" />
<item Name="Item3" />
</items>
</head>
xsd gave me a clean enough schema:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema id="head" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
<xs:element name="head" msdata:IsDataSet="true" msdata:UseCurrentLocale="true">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="items">
<xs:complexType>
<xs:sequence>
<xs:element name="item" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="Name" type="xs:string" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
Then it gave me 50k of C# code full of extra crap to read that tiny thing lol.
|
|
|
|
|
I include a property into my objects called XElement:
public XElement XElement
{
get
{
XElement value = new XElement("Item",
new XElement("Property1, property));
return value;
}
set
{
if (value != null)
{
property = GetValue("Property1", defaultValue);
}
}
}
GetValue is a heavily overloaded extsension method for the XElement class that takes care of parsing for the appropriate data type. I posted a tip/trick here:
Using Extension Methods To Avoid XML Problems[^]
After you'cve defined your XElement property, you can add a constructor to your item class like so:
public MyItem(XElement value)
{
this.XElement = value;
}
As you're reading your XML data, you can simply Add each new instance of MyItem to a collection as you read the data in.
Easy-peezy, lemon squeezy...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Hello guys,
Need some expert advise.
I am developing a c# windows application which runs as administrator.
The problem is on windows 7 and Vista, drag and drop on the application do not works when UAC is enabled. I researched a lot and found that this is because of UIPI (User Interface Privilege Isolation)
and on MSDN I found some information asking to allow the filtered messages again by using ChangeWindowMessageFilter API. I tried it and called it on form_load event some thing like this
private const uint WM_DROPFILES = 0x233;<br />
private const uint WM_COPYDATA = 0x004A;<br />
private const uint MSGFLT_ADD = 1;
//in form load i called
ChangeWindowMessageFilter(WM_DROPFILES, MSGFLT_ADD);<br />
ChangeWindowMessageFilter(WM_COPYDATA, MSGFLT_ADD);<br />
ChangeWindowMessageFilter(0x0049, MSGFLT_ADD);
But it still dont work.. may be i am missing some thing, I tried to set the property uiAccess="true" also in the manifest file and signed the exe but it still dont work.
Am i calling the ChangeWindowMessageFilter incorrectly or is there any another way ?
Can any one help me regarding this. I had to run the application as administrator as it modifies some registries
Any help would be great
Thanks in advance
Regards
abhinav
|
|
|
|
|
Hi All,
I wanted to get that hibernation option is enabled in system or not.
If it is enable then wanted to disable this option.
Thanks in Advance..
Piyush
|
|
|
|
|
|
I doubt your users want you to do that.
|
|
|
|
|
This is normally done by using Group Policy, not by any code in an application.
|
|
|
|
|
|
[background info]
For a project I'm working on I'm looking at using run-time compilation of regular cs files into an appdomain separate from the running assembly (to disallow filesystem and network access) and reference the objects the files define. This is becaues there will be alot of additions to the group of objects those files represent, while the core of the program should remain the same. I'm using the Microsoft.CSharp.CSharpCodeProvider object to do the compilation.
[/background info]
Now, I would like to expose the running assembly's public classes and interfaces so that the run-time compiled code may reference and make use of them. First and foremost it's for exposing an interface that every object compiled this way must implement. I am not completely sure how to accomplish this, even after trawling through intellisense and msdn.
Anybody got any clues for me?If I am unclear anywhere or additional info is needed, just ask!
|
|
|
|
|
Create an interface for the public properties of your running assembly, and an object implementing that interface and filled properly. Let's call it the IHost interface and the Host class.
Now you compile your dynamic code, and instantiate its objects. Those objects should implement another interface with a SetHost(IHost myHost) method. Call it with the Host object as a parameter, and now your dynamic objects can access all the properties required.
|
|
|
|
|
Your best bet would be to compile your model layer into a separate dll which can be referenced by both your main app as well as new assembly. You can reference the dll using the CompilerParameters class. I looked into this a while ago, trying to create a C# scripting engine for our app, but in the end I went with IronPython as the examples and documentation were far more widespread. The main problem I came up against was referencing Instances of objects that were created in the main AppDomain. I gave up, and I don't do that very often. Good luck, and if you get it working I would really like to see an article on how you did it. I still think a C# scripting engine would be better than Python, because we all know c# here.
|
|
|
|
|
I'm leaning towards this, and I've been pointed in a similar direction elsewhere as well. A test project let me have a simple version up and running fairly quickly,though the big stumbling block came when trying to restrict permissions for the compiled assembly. I can run the code in a restrictive, separate appdomain, but I can't do it without giving Unrestricted FileIOPermission to that domain, which kinda defeats the point I was going for. It almost seems like it needs Unrestricted FileIO in order to load the exposed assembly?
|
|
|
|
|
I also managed to get test projects running. These were really simple projects that weren't much good for real life. I did manage to get away from using System.IO by compiling the code on-the-fly using the CompileAssemblyFromSource method rather than saving to a file and compiling the source file, but I wasn't really looking at restricting access to anything. Basically I was looking at a Database management app that could handle all three database types we use(MySql, SQLServer and Access(  )), and all the users of such an internal app would have been developers.
|
|
|
|
|
I have developed something similar to this. In my case, that application did not compile cs files at runtime, but I think the idea might be the same becouse it loaded external libraries at runtime, and could use objects defined into it. Here is, basically, what I did:
1. One library where the required interfaces where defined (just the interfaces).
2. Several libraries which referenced the "interface library" and implemented them as needed to achieve their own features.
3. One main application which referenced the "interface library" as well, and loaded the libraries described in point 2 at runtime (whenever it was required), and used objects of them through the intefaces.
This is the way that my main application could be extended with modules (or plugins).
Now, for the security issues you describe I think you might use Caspol[^] to decide the permissions you give to those libraries, but I am not sure if it would work... I have not made any test about this.
|
|
|
|
|
Whoop! Got to work, at least on a medium scale! I think part of what I was doing wrong in my last post was I accidentally set up TWO levels of restrictive appdomains, i.e. the main app set up a restrictive appdomain, then run the sandboxing code in that appdomain, which IN TURN created a restrictive appdomain and tried to load my intended sandboxed assembly into it (but failed because of the first level appdomain being restrictive)
So, to summarize:
A)Create a secondary Class Library project in the solution, let's call it "Exposed", which contains everything that the cs files will have access to.
B)Gather all the cs files I want to compile. The cs files reference "Exposed" in their code.
C)Use a CSharpCodeProvider to CompileAssemblyFromFile() those files into a class library dll-file saved in the appdir.Provide "Exposed.dll" as a reference. Provide compiler options "/target:library /out:*dll-name*.dll".
---The below steps are performed by a slightly customized Sandboxer object detailed here MSDN article[^]---
D)Create the appdomain, taking care to supply a proper PermissionSet (Containing only Execution permission in this case) as well as the StrongName of the current assembly to add it as a FullTrustAssembly. Also set the ApplicationBase (in the AppDomainSetup object) to something other than your main app base directory, for security reasons.
E)Use System.Activator to load a new instance of the Sandboxer class into the restrictive appdomain.
F)The new instance in the restrictive appdomain now invokes the wanted method in the compiled library, taking care to catch SecurityExceptions.
Of course, this can be improved. Currently, the restrictive appdomain is created EVERY TIME the compiled code is called, for instance.
modified on Tuesday, March 29, 2011 7:15 AM
|
|
|
|
|
Good that you got it working. Just a reminder that anything that's created in one app domain and referenced in another must be marshalable (simple types or inheriting from MarshalByRefObject), and you might have to create proxy classes for some things which inherit from something else (I did when I wrote the plugin system for my game client).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
