I'm working on an app where there are a number of XSL stylesheets in use. These stylesheets are stored as resources in the DLL.
I want to include or import another stylesheet in to the running one. Now, I can make this work if the included stylesheet is in the same folder as the running one, but I need to include one in a different folder.
<xsl:include href ="../Folder/transform.xslt"/>
causes an error to be thown when the containing stylesheet is loaded. The server looks to c:\Windows\Folder\transform.xslt which, obviously, isn't there.
Can anyopne suggest how I do this? mI can find next to nothing about running a transform from an enbedded resource and, sadly, I have no choice but to do it this way.
Not sure exactly how it would go, but I theorize it would be done by passing a custom XmlResolver to load the references from resources.
Implement a class that inherits from XmlResolver and looks in resources instead of the filesystem (which would be location the default XmlUrlResolver would look to).
Update: It looks like MSDN has had this problem before. See http://msdn.microsoft.com/en-us/library/aa302284.aspx for an example of how to implement a custom XmlResolver.
Related
So far the only way to browse base source code in .NET is for me to use Go To Definition from my own source code in my own project. I have to type in the name of a base class/interface/etc and use Go To Definition. But is there any way to do it directly from something like Object Browser that lists them all as included across different assemblies and namespaces. The problem is that Object Browser shows only high level descriptions and it will not get you to the actual source code.
Another question is about the individual source files. Even when VS2015 takes me to the source code, it does not call it a file, just a name of class and [from metadata]. I would like to know how the concept of individual file fits into the groups of assemblies and namespaces. What kind of a database is it built into?
Application is a C# .Net 3.5 WCF Service.
I'd like during the build process to dynamically add some build information to the final binary and assemblies that can then be read programatically and sent back to the WCF client when it sends a GetVersionInfo request to the web service.
.Net assembly versioning isn't enough. I want to include additional string data that contains the state of the system at the time the application was built.
I'm thinking that I'd do this by adding a post build event to call a script to update the app.config file with the data I want. Does this sound about right, or should I be considering some other approach?
Update
I'd additionally like this string to appear in the "Special Build Description" property of the final exe. I.e. I'd like to right click on the file and see this information in the version tab for the file.
Thanks in advance.
I suspect a pre-build event may be more appropriate than post-build... have you considered adding a buildinfo.xml file (or similar) to be built into the assembly as an embedded resource? You could then load it with Assembly.GetManifestResourceStream. That way you don't need to worry about fitting in with existing files or anything like that - just overwrite buildinfo.xml with a new file in the pre-build step.
You have to decide how important it is that the information you want to exchange is tied to the executable file itself.
Updating the config file during the built is a workable model, but it places the information in a location where it could be altered by anyone with access and a text editor.
Updating information after a build in a compiled assembly is certainly possible, but it's fragile and breaks down if you ever decide to sign the assemblies. It's also a lot of work, since there's no built it support for re-writing assembly files in this manner.
An alternative you should consider, is creating your own custom assembly-level metadata attributes and assigning them during the build process. You could even place them in a separate code file (or append them to AssemblyInfo.cs) as part of you build.
You could also consider creating an embedded resource (an XML file, for instance), and retrieving it from the assembly manifest at runtime.
Either of the above approaches would require you to use a pre-build custom step rather than a post-build step.
Personally, I find the metadata attributes a convenient approach if there isn't a lot of data. Otherwise, I would consider using an embedded resource file.
When you compile a C# project, the app settings from app.config are saved along with the exe file. For example, if the program name is "solve_np.exe", there will be a "solve_np.exe.config" next to it, making it look less neat than I want it to. How can you embed it into the .exe?
I tried to set Build Action to Embed Resource, but that did not do the trick.
Aha. I guess you're falling foul of Visual Studio automatically placing stuff in configuration that you DONT want configured by the end user.
In this case use resources. Simply add a new file of type .resx. With this you'll be able to add things like strings and images to the resource file. After you build this it should provide static access to the resources (it typically generates a code file from the resources for you so you don't have to access ResourceManager yourself).
E.G. If I made resources.resx with a string called MyConfigValue after a build I should be able to access this like:
textBox.Text = Resources.MyConfigValue;
If you want values that are kinda variable but shouldn't be configurable then this is the right place to put them.
HTH.
It isn't unprofessional to have an app.config file shipped alongside your exe. I think the word you may be looking for is untidy. I personally don't find this is the case myself however everyone is different! Perhaps you could simply make the app.config file hidden by default?
Or another alternative is to create your own config file which you could save to the App Data folder or even storing the settings in the registry instead.
Here's another factor to consider. Seasoned .Net developers are accustomed to the standard application design, which incorporates using config files in both web apps and desktop apps. If you depart from that practice, you will make it more difficult for any developers who follow you to understand what you have done. Even sa's on the web server may be confused by the absence of a config file.
Since pretty much everybody does it this way, your code does not look "untidy" to others. On the contrary, it would be befuddling not to see a config file where one is expected.
Typically the theory of a configuration file, is that it stores settings you may want to change once you've deployed the application (for something like user preferences). To do this, you need to be storing somewhere external to your application. If you use the default setup, you get "[Your].exe.config". There are many other options you could look at, but nearly every one of them ends up with a file written somewhere, if you providing a mechanism that saves settings of some kind.
I agree with serhio darasd and Quibblesome but you can just delete "solve_np.exe.config" and it'll just use default configs.
After considering what was written in these comments and other searching, I decided that the best way to handle my issue of wanting my Entity Framework connection string to be embedded into my executable instead of needing the MyApplication.exe.config file with my deployed solution was to created a derived class like such:
Public Class MyEFDataContainerLocal
Inherits MyEFDataContainer
Public Sub New()
MyBase.New(My.Settings.MyEFContainerConnectionString)
End Sub
End Class
I just created an Application Setting of type Connection String that contained the same string as what is found in the App.Config file. I just had to replace the "e;'s with actual quotes.
Then whenever I wanted to use the MyEFDataContainer as in Dim db As New MyEFDataContainer I would just use Dim db As New MyEFDataContainerLocal instead.
Alright, so I'm working on programming my own installer in C#, and what I'd like to do is something along the lines of put the files in the .exe, so I can do
File.Copy(file, filedir);
Or, if this isn't possible, is there another way of doing what I am attempting to do?
I wouldn't code my own installer, but if you truely want to embed files into your assembly you could use strongly typed resources. In the properties dialog of your project open up the "Resources" tab and then add your file. You'll then be able to get the file using:
ProjectNamespace.Properties.Resources.MyFile
Then you'll be able to write the embedded resource to disk using:
System.IO.File.WriteAllBytes(#"C:\MyFile.bin", ProjectNamespace.Properties.Resources.MyFile);
Honestly, I would suggest you NOT create your own installer. There are many many issues with creating installers. Even the big installer makers don't make their own actual installers anymore, they just create custom MSI packages.
Use Mirosoft Installer (MSI). It's the right thing to do. Make your own custom front-end for it, but don't recreate the already very complex wheel that exists.
UPDATE: If you're just doing this for learning, then I would shy away from thinking of it as "an installer". You might be tempted to take your "research" and use it someday, and frankly, that's how we end up with so many problems when new versions of Windows come out. People create their own wheels with assumptions that aren't valid.
What you're really trying to do is called "packaging", and you really have to become intimately familiar with the Executable PE format, because you're talking about changing the structure of the PE image on disk.
You can simulate it, to a point, with putting files in resources, but that's not really what installers, or self-extractors do.
Here's a link to Self-Extractor tutorial, but it's not in C#.
I don't know enough about the .NET PE requirements to know if you can do this in with a managed code executable or not.
UPDATE2: This is probably more of what you're looking for, it embeds files in the resource, but as I said, it's not really the way professional installers or self-extractors do it. I think there are various limitations on what you can embed as resources. But here's the like to a Self-Extractor Demo written in C#.
I'm guessing here, but if you are trying to store resources in your application before compilation, you can in the Project Explorer, right click a file you would like to add, chose properties and change the type to Embedded Resource.
You can then access the embedded resources later by using the instructions from this KB:
http://support.microsoft.com/kb/319292
in case you simply want to store multiple files in a single file storage (and extract files from there, interact etc.) you might also want to check out NFileStorage, a .net file storage. written in 100% .NET C# with all sources included. It also comes with a command line interpreter that allows interaction from the command line.
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?