Develop Reference

Does the .NET binary serializer encode assemby information?

I've been developing a game and part of the process was going to be a custom level tool and file format. I had created a small console application that generated a 'LevelAsset' object which contained only primative data types. The problem arises when I try to deserialize that data within my unity game. I didn't copy any code from my console app and rewrote both the 'LevelAsset' object and Deserialization code from scratch. Yet when I run the game, I get an error saying I'm missing the "Level Tool, version=1.0.0.0" assembly, which is from my original console app. How is this occuring. Is the binary serializer encoding information about the project?
Edit: So upon further investigation it appears that the BinnaryFormatter does indeed include information about the project in the form of a file header. So my new question is now: How on earth do I serialize without headers?

So after a bit of digging its fairly obvious whats happening. BinaryFormatter does indeed encode project information in its file headers. If you want to avoid this you should use binary writer instead.

When I build a Silverlight project, what happens to XAML files?

Can you please explain the life-cycle of an XAML file in terms of compiling?
When I build a Silverlight project what happens to a XAML file in the build process?

The answer about the intermediate .g.cs file by Jon Skeet (now deleted, but that part quoted below for context) was partly correct but did not answer your actual question in full:
JS: An early part of the build process creates a Foo.i.g.cs file in the
obj directory containing a partial class, and that gets compiled in
the normal way along with your own .cs files.
The .g.cs files contain pieces missing from the code-behind required to connect named elements to class members during InitialiseComponent(). e.g. this is from a basic MainPage.g.cs:
public void InitializeComponent() {
...
System.Windows.Application.LoadComponent(this, new System.Uri("/SilverlightApp1;component/MainPage.xaml", System.UriKind.Relative));
this.LayoutRoot = ((System.Windows.Controls.Grid)(this.FindName("LayoutRoot")));
}
This is bit like the designer files generated for WinForms controls/dialogs, but happens at compile time instead of design time.
The compiler parses to validate the XAML and to determine what named elements need to be generated (into the partial class).
The XAML file itself gets stored as a resource in the DLL during the build (in the example above it is stored as "/SilverlightApp1;component/MainPage.xaml")
Note: For WPF only, the embedded XAML file is actually converted to a more memory-efficient binary version referred to as a BAML file.
Answering your comment to Jon Skeet (now deleted), you are partially correct in asking:
So parsing the whole XAML document -all the elements, attributes etc.-
is not part of the WPF or SL builds? Am I correct?
Aside from the parsing mentioned above, for validation and named elements, the rest of the parsing (of the element tree and templates etc) is actually done at runtime when LoadComponent() effectively deserializes the XAML and creates a visual tree of elements you authored.

When you build a Silverlight project a .xap file is created, this is basically just a .zip-file with another extension, containing an AppManifest.XAML and your project in a DLL-file (together with DLL:s for other dependencies).
If you run the DLL through dotPeek or Reflector you'll see that the XAML-files you created are found intact in the resources of the dll.

How to create XSD file programmatically in C#?

I have a xml file (that i created in c# using XmlDocument) and now i have to create xsd file the corresponds to it also programmatically in C# ... how can I do this ??
can I use the same classes for creating xml files ? or are there any other (xsd related) classes I should use ??

If you just want to produce an XSD file from an XML file, then you can use Microsoft's XSD.EXE, which is included with Visual Studio.
To use it, open a Visual Studio Command Prompt. Then enter xsd file.xml to produce a schema for that XML file.
You can also use that tool to generate classes for your XML input, just pass in the /classes parameter.

While an XML Schema file is an XML file, it has certain things that could make it cumbersome to do it "by hand"; one could say why write XML using the DOM API instead of using C# classes generated by XSD.exe or XSD2Code.exe? Or to push it a bit... somewhat similar to someone saying C# statements eventually turn into IL assembly; why not write IL instead?
Another alternative is provided by the Schema Object Model API; in .NET, it is the System.Xml.Schema namespace.
Take a look at the code example found here on MSDN. It'll give you an idea for another approach. It provides a programmer friendly API to generate XSDs, instead of dealing with the actual XML.

XSD is just another XML-type file. whatever you are using to create your XML file will also be useful to create the XSD file; you just need to know what tags/attributes you want to put in the file...

Solution:
I originally posted a reply, but Stack Overflow rather I edit my response, so here is the edit. The original tool that I suggested goes the other way. I then did some research and someone recommended a tool called MyGenerations or something like that. That required an installation, downloaded template, and oodles of work, so way too complicated. I then did some more research and came across a rather nifty solution on CodePage, but that solution, which works, because I tested it, requires some modifications. The code is called XmlToXsd with the URL:
http://www.codeproject.com/Articles/133570/XmlToXsd-A-Better-Schema-Generator.
The Programs section has two bugs. First it saves the XSD to the executable's root. Do not worry, the exe merely calls a method located in one CS file. Simply include that CS file in your project and call with the line given, just you have to change the path to the same folder as the XML. Additionally, the author uses a targetnamespace of a junk URL. DevExpress throws a complaint on the nonexistent URL. Through some effort, I replaced the target URL with null. In the accompanying CS file I had to make a few changes. Others with more understanding than I can modify to his/her hearts extent. I merely help others by telling them what I did, so no static back.
Change 1: Before "target = XNamespace.Get(targetNamespace);" add an if-statement only loading if not null for the target namespace.
Change 2: I added another if-statement for the return. The null return, a copy of the original return modifies as follows:
2.1: Nuke the targetnamespace attribute item.
2.2: After the replace call, add another replace call of ".Replace("xmlns=\"null\"", null))".
2.3: Before the return, requires adding braces, set target = "null".
The resulting file now appears totally valid and created programatically.
Yes, one can use XSD.exe but manually, but I needed a programatic way of the conversation.
Original Post:
I had the same question, not necessarily programatically. The XSD utility does do the job. The problem is that Microsoft does not distribute xsd.exe with Visual Studio 2012 Professional. I searched my hard drive and found the utility with Microsoft's SDK, path on my disk "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64\xsd.exe".
I had to go to the folder where the XML file is and execute XSD utility from a command box (not in Visual Studio) and wound up with the XSD file.
One way to do this task programatically is to call XSD from code, but that would mean distributing XSD.
I found this one assembly, but never used it that might do the job. Check out: http://xsd2code.codeplex.com/

Try this:
string xmlFilePath = #"myxmlfile.xml";
string xsdOutputPath = #"myxmlfile.xsd";
DataSet ds = new DataSet();
System.IO.FileStream fsReadXml = new System.IO.FileStream(xmlFilePath, System.IO.FileMode.Open);
ds.ReadXml(fsReadXml);
ds.WriteXmlSchema(xsdOutputPath);
If from xDocument:
DataSet ds = new DataSet();
ds.ReadXml(YourXDocument.CreateReader());
ds.WriteXmlSchema(xsdOutputPath);

Advantages and usefulness of adding an XML file to a Visual Studio 2008 project

What is the advantage of adding XML files to a visual studio 2008 project (windows form app project for example).
Once added to the project, how could I refer to this XML to use it in a class in the same project? In this case, I would be sending it as a query to a web service.

If you want to use the XML in some form, you could mark it as a "embedded resource" in the properties window, and then access it from your code like so:
Assembly a = Assembly.GetExecutingAssembly();
if(a != null)
{
Stream s = a.GetManifestResourceStream(typeof(yourType), "YourXmlName.xml");
if (s != null)
{
String xmlContents = new StreamReader(s).ReadToEnd();
}
}
Once you're done, you have the XML file's contents in "xmlContents", if all goes well.
Marc

I guess the advantage of having your XML reside there in your project (or solution even) is that you can maintain it in VS with nice formatting and even intelli-sense, but then using something like XML Spy or whatever can give you that too.
To refer to it in a class you'll need to ensure you have access to it, and that it resides in a reliable place.
In the past I've used post build events to move the latest copy of the file to where I need it. As Arnshea writes here is another answer, "to the output directory". You can use the "Copy to Output directory" property on the XML file itself to achieve this. Then your classes can use the XML file, knowing it will reside in a reliable place.
You'll need to make sure it's accessible though especially if you're writing back to it. Make sure it doesn't end up "Read Only" - as Source Control system could do to you. Storing these files in a folder under Program Files could also be problematic especially on Vista, where user privileges are (should be) restricted.

If your app needs to load the XML it can be copied to the output directory. Also simplifies use of Setup/Deployment projects...

Another major advantage would be (assuming it's in place--and it should be!) is that you can apply revision control to the XML file.

I guess that you won't be sending the same XML file to the WebService over and over again.
You will want to modify its content every time for that you have XML Serialization.
If all of the above apply then you don't need the XML file, you just need the class that generates the file at runtime. The XML is just the transport, today its XML and tomorrow it might be some other format (JSON).

Can intellisense be exported or extracted from Visual Studio to a text file?

I'm trying to write some documentation for a webservice that has been provided by one of our vendors for an application we're integrating. A bunch of the interface is custom objects defined in the web service itself. The vendor has put up significant resistance to providing any documentation for this application and so I've taken it upon myself to do their job for them [against my better judgement].
The documentation they have provided frankly is embarassing and I'm trying to make as short work of this as I possibly can to put some good quality docs together. I know that as I don't have access to their source, I can't just run it through nDoc/Sandcastle to spit out an API doc, but I was wondering if (as a half way house) there was an easy way to export the intellisense to a text file without me having to write a utility to specificially iterate through each of the object types defined and reflect the members out to text?
If I could do this, it would at least make sure that I have a good quality document structure where I can just fill in the blanks. Having to skip back and forth to Visual Studio to check the intellisense for every class member is a very laborious way of doing this.
Does anyone have any ideas?

If it is a web service that you are trying to document, couldnt you then parse out the WSDL?

If you are accessing a remote Web Service, then I think you have access to the corresponding WSDL: what about parsing it and look for just the information you need?
Or using a tool to do this (I Googled for "wsdl documentation generator")?
Or even using WSDL.exe to generate some dummy code from the WSDL and then document it, perhaps helped by GhostDoc?
HTH

Could you use Reflection to dump out the methods etc.?
Reflection is the feature in .Net, which enables us to get some information about object in runtime. That information contains data of the class. Also it can get the names of the methods that are inside the class and constructors of that object.

I think VS.net generates documentation for intellisense. For existing assemblies, it is already on your file system (e.g. C:\Windows\Microsoft.NET\Framework\v2.0.50727\en)
Try using the assembly from the vendor in VS.NET. Use process explorer or any such tool from sysinternals to see what files are being loaded. I am sure, you will find that there is an xml file created for the custom assembly (which is used to show the Intellisense and documentation available with it).
Hope that helps.
EDIT: I think the same folder (where your custom assemblies are located) will have the xml files for documentation.

If you have the dll's could you not decompile them and then recompile and use nDoc? That should give you a reasonalbe start.

Could you just use reflector (from redgate) to view the assembly (decompiled) instead of reproducing a API document. I'm not sure what else you would get of reflecting and building your on document that you wouldn't see live in reflector (of course this would depend on their writing readable code.

Maybe this is crazy, but could you take a screenshot of the full listing, and run it through an OCR program?