We're trying to learn to use T4 Templates. I have a desire to use the System.Data.Entity.Design.PluralizationServices library in order to better pluralize some Entity Model names within my template, but I've come across some issues in the achievement of this goal.
Running code to generate output text. I think this is possible, but if it's not going to work, then there's no need to go any further. (I could call Date.Now.ToString() and get the expected result. I haven't tried anything much more complicated yet)
I am in a Silverlight App, and so I can't add a reference to the project for the PluralizationServices library in the place where I need the generated .cs file. I was planning on just moving the .tt file to a non-SL app, using the namespace and moving the generated file to the correct space. Haven't got that far yet, so I don't know how much trouble that will be, but it doesn't seem like it should be too hard.
My current problem is that when I import the namespace of the library, I get an "ErrorGeneratingOutput" and I haven't been able to move on past that yet.
I am having a hard time finding information about how the import command works, so I assume that it's just obvious. At the same time though, this one doesn't work so I wonder if it might be an exception to the standard.
<##import namespace="System.Data.Entity.Design.PluralizationServices" #>
I have no idea why adding this line (and only this line) causes everything to break. I haven't even started to try to use it yet! Is there something somewhere about libraries in T4 that I should know or read? Thanks!
Here a description of how the import directive works. Without knowing the actual error T4 reports when transofrming the template in your environment, I can only guess that you didn't add an assembly directive to reference the System.Data.Entity.Design assembly. If this doesn't work, look at the errors reported by T4 in the Error List of visual studio, which should be more helpful than "ErrorGeneratingOutput".
Related
I have multiple assemblies for a library that I merge into a single assembly with ILmerge, using the /internalize flag. Additionally I also merge the xml docs generated by the compiler into a file using the /xmldocs.
The following question may sound bizarre but there is a reason behind:
Is there a way to remove the internalized methods documentation from the documentation xml?
Why? Because in a second step, I obfuscate the merged assembly. All internal methods are going to be renamed/modified and the documentation is therefore useless and even worse: it does reveal information about the obfuscated part.
I want to be able to store multiple FlowDocuments within a single package, including images, etc. within each document. However, none of the methods I've seen for saving (and loading) Xaml FlowDocuments seem capable of this.
TextRange.Save with DataFormats.Xaml strips images and other embedded content
TextRange.Save with DataFormats.XamlPackage creates a whole new package, rather than allowing me to treat the document and included images as parts within the package I'd be storing it in
XamlWriter looks like it could be good for this, but I can't figure out how to find all the embedded objects for putting in their own parts (although I certainly know how to handle them once I've found them). On the other end, I haven't a clue how to make everything load properly later on.
It's pretty annoying that there's no one-stop way of serializing a FlowDocument and its images, etc. to a PackagePart. If anyone's figured out a good way of doing this, how'd you pull it off?
UPDATE 2011-07-03 00:22: Using XamlWriter and some extra code from this question I've been able to build a happy little OPC-compliant package which can hold multiple FlowDocuments including their images, as PackageParts. However, going the other way (from PackagePart to FlowDocument) is failing, because no matter how I try to load the document, I get XamlParseExceptions telling me that
'Initialization of 'System.Windows.Media.Imaging.BitmapImage' threw an exception.'
So, the question now becomes, how do I manhandle XamlReader.Load and/or my part's stream in order to get the related images loaded properly?
Figured it out. The solution is to manually process the Xaml document before handing it over to XamlReader. Images (and other elements stored as their own PackageParts) need to have the BitmapImage.UriSource property set to include the package Uri (for example, "./Image1.png" in /Content/Document.xaml to "pack://file:,,,C:,Projects,Package.pak/Content/Image1.png").
Two caveats, however:
There's an issue with PackUriHelper.Create(Uri,Uri) however. Instead of using
PackUriHelper.Create(packUri, part.Uri))
you have to use
new Uri(packUri.ToString() + value)
where value is part.Uri with the initial / removed. If you don't do this, instead of getting a proper Uri like above, you get one with an additional comma after the package file name, which confuses and annoys XamlReader.
You need to use FileShare.Read when opening the package, as XamlReader will try and open it itself. By default, Package.Open locks out anyone else trying to open the package, and XamlReader.Load will throw a WebException if it can't get into the package itself.
I have a code library that makes heavy use of XPathNavigator to parse some specific xml document. The xml document is cross-referenced, meaning that an element can reference another which has not yet been encountered during parsing:
<ElementA ...>
<DependentElementX id="1234">
</ElementA>
<ElementX id="1234" .../>
The document doesn't really look like this, but the point is that 1) there is an xml schema that enforces the overall document structure, 2) elements inside the document can reference each other using some IDs, and 3) there is quite a few such cross references between different elements in the document.
The document is parsed in two phases. In the first pass I walk through the document
XPathDocument doc = ...;
XPathNavigator nav = doc.CreateNavigator();
nav.MoveToRoot();
nav.MoveToFirstChild()...
and occasionally 'bookmark' the current position (element) in the document using XPathNavigator.Clone() method. This gives me a lightweight instance of an XPathNavigator which I can store somewhere and use later to jump back to a particular place (element) in my document.
Once I have enough information collected in the first pass (for example, I have made sure there is indeed an ElementX with an id='1234'), I jump back to saved bookmarks (using those saved XPathNavigators) and complete the parsing.
Well, now I'm about to use this library in Silverlight 3.0 and to my horror the XPathNavigator is not in the System.Xml assembly.
Questions:
1) Am I missing something obvious (i.e. XPathNavigator does exist in some shape or form, for example in a toolkit or a freeware library)?
2) If I do have to make modifications in the code, what would be the best way to go? Ideally, I would like to make minimal changes, not to rewrite 80% of the code just to be able to use something like XLinq.
To resume, in case I have to give up XPathNavigator, all I need is a way to bookmark places in my document and to get back to them so that I can continue to iterate from where I left off.
Thanks in advance for any help/ideas.
You are not missing something obvious, there is no implementation of XPathNavigator or XPathDocument in the Silverlight versions of the libraries.
The "best way to go" is highly subjective and would really depend on how many lines of code are really depending on XPathNavigator. However I see a couple of choices.
Go ahead and re-write the code using XDocument, XElement etc from the System.Xml.Linq namepsace. This may not be as bad a choice as you might think.
Wrap Xml-to-Linq objects in your own implementation of those properties and methods of the XPathNavigator that you are actually using. It shouldn't be too hard re-create most the features of the XPathNavigator against the Xml-to-Linq objects. You can then run your existing code against your own XPathNavigator.
XPath (xdoc.XPathSelectElements) is available in Silverlight 4: here's an online test tool.
There are tons of ways:
How to deal with XML in C#
You can still use Linq to XML just minus the linq syntax and use the Linq Extension methods.
I am using plugins for one of my Mac OS X(desktop) application. These plugins refer to a common file that contains base class implementation of both the plugins.
When the application refers to this common base class, the following message is displayed in the console by the system:
" is implemented in both and . One of the two will be used. Which one is undefined."
This console message is displayed from 10.5.x onwards.
However this does not cause any problem. But, I do not want my class name to be printed in the console. Can someone help to avoid this console message.
A possible way around is to #define the name of your class as something unrelated, so that it remains the same in your code, for your use, but is obfuscated in the executable.
I'd like a neater solution myself. I have searched quite a lot, and it seems that in general console messages are for solving problems, rather than for looking for them, and more specifically that this kind of message isn't really an issue.
One can also use an EXPORTED_SYMBOLS_FILE or an UNEXPORTED_SYMBOLS_FILE (these are the relevant build setting names) to state which symbols you do or don't want to export. Often, you want to export at least one, but it can reduce the number of names that are revealed.
Does someone know a library that I can use to read MP3 tags in Silverlight 3?
In WPF I was using taglib, but obviously I cannot reference it in Silverlight projects.
Taglib doesn't contain any unsafe code. Perhaps you can recompile it (with a few minor alterations maybe) to work in silverlight.
Have you tried just using Taglib's code? There's a decent chance it'll work without too much hassle.
Edit: Yes, I mean TagLib#. I just tried, and there are a few minor issues which were fixable in 15min. (You'll need to define ICloneable, remove a bunch of unnecessary Serialization constructors for exceptions, remove the last parameter on string.Split(char[],int) calls, that's about it.)
Note that unless someone else has fixed it, there's a minor bug in Taglib#'s Id3v2 unsynchronization code. You can ignore it and fail to parse a few id3v2 tags, or you can use the same workaround I did: https://bugzilla.gnome.org/show_bug.cgi?id=593138#c4 - I know, I should submit a patch, but time and all...