Im about to create some settings for MVC projects and sites, based on dynamic variables etc.
These settings will be stored in xml for easy read and write.
My question now, after reading about extending the intellisense in this question:
Is it possible to provide intellisense for dynamic objects in visual studio?
Is if its possible to read my saved settings (which are stored at runtime) and then for the next run build a intellisense from that?
I.E. for each of these site.setings.layout.width a list of the "older" saved xml-defined defined dynamics will be able to show up?
If all you need is xml "intellisense" then consider designing xml schemas and dump them in Visual Studio installation Folder\xml\Schemas or include them in your solution and VS will do the rest if the namespaces match appropriately.
Edit:
Coming back to this after a while. No other answer appears to have been given so I'll try to be more creative.
Visual Studio has an option to generate an xsd from an xml file. Note that the schema will be mostly an approximation but it will match the file and will be a good description of structure. If you could find a way to call that from a command line (or possibly find a similar tool for the step) you can then chain that with xsd.exe and generate C# classes from it at build time (prebuild step)
If point one is too cumbersome you could try to write a T4 template that reads a previous configuration file and generates your custom code based on that. Generating a POCO property structure based on some xml should be fairly simple with T4. The template should be run as a precompiled step.
Note that both suggestions involve static code generation. A full dynamic solution could be done with F# type providers but that is not available for C#.
Related
Using Visual Studio Community 2017 and C#.
I have for while now identified the need to have some better view of all the initialization data I have in my different class objects.
Today all the data are stored and initialized in the constructors. And if you have like 40 models of car classes and each class has its own properties of speed, weight, engine power and so on, you don't get such a good overview of the initialization data.
I am making a game with a lot of different objects and I would like to have the data in spreadsheets and I want that data to be imported/read to my objects at compile time not at run time since I don't want to distribute the data files with the application.
I've been looking around, and searched to the end of my ability in finding the right keywords but...no. Maybe you can help me?
You could use T4 templates to generate the configuration code for you from another source such as XML (or spreadsheets if need be)
You can add post build tasks to do this after each build or run the template manually when configuration changes.
A good sample can be found here
I have been asked to create a project which involves loading profiles into a UI in which the user can edit the values. I need to be able to load data from a file within the project and allow the user to make chnages and save back to that file.
All of this has to be contained within an executable but I am unsure of the best way to approach this, I was think of using an XML file with an XML structure or a text file and just string split on it or even a resources file and just call out to it.
I thought I would put my problem up on here and see what the community suggest, thanks!
Embedded resources are not intended to be changed during runtime. A database is really easy to auto-create these days using code-first EF, but a file containing XML or JSON would also be a good option (as there are third-party libraries to help you parse the result). Hand-rolling your own string.split solution is not recommended (because if requirements get more complex in the future, your code may become unmanageable)
I am trying to find an article I read about a month ago. I the article the author talk about using the XML classes in .net to map xml with a schema to POCO objects and also showed how to create a schema straight from the objects that he had. This is exactly what I'm trying to do know, but all I seem to be able to find is articles talking about manually walking through the xml and extracting the values for your objects.
I know I can manually spin through the XML to get my objects, but I have several different objects I need to map, so I'd rather go down the automated route if there is one. Does anyone know how to build a schema from a .net object and then map XML files to it with some .net automagic?
The xsd.exe command-line utility is your friend!
See the MSDN docs for details on how to use it and what you can do with it.
In brief:
It can take a .NET assembly and generate XSD schema for each of the classes, or it can take an existing XML file and generate a XSD schema from it (as good as it can guess it), and then a C# or VB.NET class from that schema that allows you to easily deserialize a XML file into a .NET object directly.
There's also Xsd2Code - a Visual Studio (at least 2008 - not sure about 2010) plugin that allows you to have a XSD file in your project, and create a C# class from it in the Solution Explorer.
I am attempting to build some classes so that I can deserialise an XML file created by a third party application. Luckily the developer of the 3rd party application included a schema file with their code so that the XML file can be understood.
When I use the XSD.exe tool from Visual Studio the process fails reporting the following error
"Group 'SegGroupOrSegmentGrouping' from targetNamespace='' has invalid definition: Circular group reference."
Any help in how I can generate the class files in light of this error would be appreciated.
A copy of the schema file can be found here : schema file
Try using svcutil; it can handle the circular references.
In the following example, eExact-Schema.xsd is an XSD that xsd.exe cannot handle.
Example:
C:\SRC\Exact>svcutil eExact-Schema.xsd /language:C# /dataContractOnly /importxmltypes /out:exact.cs
This is always a good place to start; you can now use this class and alter to suit your style/needs, add comments, etc, and it will save you a lot of time/searching over doing it all from scratch.
I had this same problem recently,
I was given a Schema from a third party company who were returning an xml structure from a webservice. I then wanted to deserialise the response and store the information into a database with NHibernate.
No problem I thought I'll just use xsd.exe and I'll have my classes. Unfortunately this was not to be. Xsd.exe failed with exactly the same error you are getting. This is because it is unable to resolve circular references.
I spent a good few days looking at alternatives until in the end I wrote my own class structure to the schema and was able to deserialise perfectly. The answer here is to write your own C# classes and decorate them with the appropriate attributes.
Save yourself some time and heartache and don't continue to try and generate the classes you need automatically in the end although time consuming the classes you write won't make the compromises that most tools (which don't work perfectly) will make you make.
Took me about 3 days to write the class structure (it was large) but I ended up with a quality solution.
One thing is certain you will not be able to use xsd.exe and most other tools I tried after googling this either did not work properly or were buggy.
After trying several third party tools, I found that Liquid Technologies has a very robust generator called Liquid XML Data Binder 2012. It was able to handle the circular group reference problem I faced. It can generate code for just about any version of .net from 2.0 on. The classes it generates do depend on a redistributable dll that they provide. I'm using the trial version and I wouldn't be surprised if a purchase of the full version will be necessary before I go to release. However, having saved me probably a hundred hours or more of error prone hand coding, I can't complain.
The easiest method for me is to create the XSD file from the actual XML file with XSD.EXE. Then create a class from the new XSD file. You may be required to modify the class periodically if nodes or types are introduced that did not exist in the original XML but you will save yourself HOURS of coding time!!!!
I am looking at creating a small class generator for a project. I have been reading about CodeDOM so it the semantics of creating the classes does not appear to be an issue, but am unsure oh how to best integrate the generation into the development and deployment process.
How should I trigger the creation of the classes? I have read it should be part of the build process, how should I do this?
Where should the classes be created? I read that the files should not be edited by hand, and never checked into source control. Should I even worry about this and just generate the classes into the same directory as the generator engine?
Take a look at T4 templates (it's built in to VS2008). It allows you to create "template" classes that generate code for you. Oleg Sych is an invaluable resource for this.
Link for Oleg's tutorial on code generation.
The answers to your question depend partly on the purpose of your generated classes.
If the classes are generated as a part of the development, they should be generated as text files and checked into your SCM like any other class.
If your classes are generated dynamically at runtime as a part of the operation of your system, I wouldn't use the CodeDOM at all. I'd use Reflection.
I know of the presence of T4 templates (and know many people use them), but I have not used them myself. Aside from those, you have two main options:
Use a SingleFileGenerator to transform the source right inside the project. Whenever you save the document that you edit, it will automatically regenerate the code file. If you use source control, the generated file will be checked in as part of the project. There are a few limitations with this:
You can only generate one output for each input.
Since you can't control the order in which files are generated, and the files are not generated at build time, your output can only effectively be derived from a single input file.
The single file generator must be installed on the developer's machine if they plan to edit the input file. Since the generated code is in source control, if they don't edit the input then they won't need to regenerate the output.
Since the output is generated only when the input is saved, the output shouldn't depend on any state other than the exact contents of the input file (even the system clock).
Generate code as part of the build. For this, you write an MSBuild targets file. For this, you have full control of input(s) and output(s) so dependencies can be handled. System state can be treated as an input dependency when necessary, but be remember that every build that requires code generation takes longer than a build which uses a previouly generated result. The results (generated source files) are generally placed in the obj directory and added to the list of inputs going to csc (the C# compiler). Limitations of this method:
It's more difficult to write a targets file than a SingleFileGenerator.
The build depends on generating the output, regardless of whether the user will be editing the input.
Since the generated code is not part of the project, it's a little more difficult to view the generated code for things like setting breakpoints.