Make Ms Word file part of dll - c#

We have a class library project that is using Gembox which we use to create pdf files. Part of the workflow is to read templates from .docx files. We would like to embed these word file in the dll file that is created by the build, at the moment they are placed next to the dll file in the bin-folder.
Any suggestions in how we can solve this?

Add them to your resources file:
Then you can access them like this:
byte[] fileData = ProjectsNamespace.Properties.Resources.file;

Related

Resources folder in Visual Studio

I write you all for a problem with my c# library. It needs an XML file that uses as a dictionary. Since the files will not change I would like the dll already contained the file and requires no memory references to it.
System.Xml.XmlTextReader reader = new System.Xml.XmlTextReader(#G:\Project\dictionary.xml");
So I put the XML file in the "Resources" folder of visual studio, but now I do not know how to get that file. If you always use the memory reference to use the library without also enter the file, it does not work. How can I do? If I open the dll with a notepad I see that the XML file is in.
This should give you an idea:
add a *.resx file
drag and drop you XML File onto it.
Use it!

Use DLL file in my URL link , c#

I'm writing a c# code to do :
1- get file file zipped folder.
2- add file to zipped folder.
3- if the file is Image then do compression and re-size the image with some conditions.
and its working perfectly :)
i need to put the code inside a library and build it so i can get a DLL file, and that's easy too i have no problem with it.
the problem is: how can i pass parameter to that DLL file. i need to use it like this:
<a href='myDLL.dll?image=XX&width=XX&height=XX&compression=XX' />
please help me on this.
I think it is not possible to call a dll from html, why you didn't use a HttpHandler for this?
In order to create a dll file which can be usable by other project, you should create a new "Class Library" project. This is a specific type of a project which returns only a .dll file as a result. Then you should add this dll to your other projects in order to use the functions.
Here is more info about the topic:
MSDN Class Library

Saving multiple files types into one file

I'm developing a 3D application in which the user may load multiple images, the 3D library I use has a function to export the whole scene as XAML, of course in XAML I only have the path to the images, so the file will only be valid on the machine in which it has been created, what I want to do is to save the XAML , change image(s) path inside the XAML to be relative to the XAML file path, save image(s) along the XAML in the same new file, like this the new file will always contain the XAML and the images. how to save multiple files types within the same file ? any other suggestions on the whole idea would be appreciated.
If you are using .NET 4.5, then you can programmatically save multiple files into a zip folder easily using the new ZipFile class.
First, you'll need to prepare your files into a new folder (Directory.CreateDirectory, File.Move) and then you can simply use the ZipFile.CreateFromDirectory Method (adapted from the linked page):
string filePathOfNewFolder = #"c:\example\start";
string zipFilePath = #"c:\example\result.zip";
ZipFile.CreateFromDirectory(filePathOfNewFolder, zipFilePath);
UPDATE >>>
For .NET 4, you might have to rely more on third party libraries. You can download the DotNetZip library from the DotNetZip - Zip and Unzip in C#, VB, any .NET language page on CodePlex. It also works fairly simply. Here is an example taken from the linked page:
using (ZipFile zip = new ZipFile())
{
// add this map file into the "images" directory in the zip archive
zip.AddFile("c:\\images\\personal\\7440-N49th.png", "images");
// add the report into a different directory in the archive
zip.AddFile("c:\\Reports\\2008-Regional-Sales-Report.pdf", "files");
zip.AddFile("ReadMe.txt");
zip.Save("MyZipFile.zip");
}
Store your XAML and other image files into one file (e.g. zip or cab).
When running your program, unzip relevant file into a temp folder so you can get the relevant path working.
Empty the temp folder afterwards if required.

Accessing an excel Project from A Winform Project in same Solution

I am trying to open an excel project in my Solution from a Winform Application. Please note:
Winform is my starting Project.
I can add Winform Reference in Excel but I can not add Excel Reference in Winform Project.
As I mentioned I cant find Excel Project in ADD REFERENCE>SOLUTION of Winform project. I also cant add it manually (Invalid dll or COM file Error!).
Any idea?
To open up excel you can use this:
Process.Start("excel.exe"); // or the real path of excel
And to have it open up with a certain worksheet, you could pass as an argument the path of the file:
Process.Start("excel.exe \"c:\My Folder\book1.xlsx\"");
i think iam not really getting what you mean but if you need to open the excel file with one click in the app
and you dont want to write the path of the excel file (may be because you want you app portable)
so the answer is to 1- put the excel file anywhere in the project folder
2- add existing item (. filter) and select the excel file
3-change the properties of the excel file
build action: resource
Copy to output directory:copy always
4-open the properties of the solution and click resources the drag the file and drop it
5-use the (using system.reflection & using system.io & using system.resources)
then write the code like this
string sPath = Path.GetTempFileName();
File.WriteAllBytes(sPath, Properties.Resources.excel File name here);
then take that (spath) and use it as your path so then you can change the project location with the excel file inside it and it will still be working without writing a constant path for it

System.IO.Packaging library does not read standard windows zip files

When reading a zip package using the System.IO.Packaging assembly, I have found that zip files created using the standard windows zip utility are unable to be read (the package parts (internal files) of the zip package show as not existing).
After doing some research it appears that this is because the System.IO.Packaging library adds a Content_Types.xml to the zip when it is created, which does not appear to be present in a standard windows compressed zip.
Example:
using (Package Zip = Package.Open(BundlePath, FileMode.Open))
{
Uri FileUri = PackUriHelper.CreatePartUri(new Uri("somefile.xml", UriKind.Relative));
if (!Zip.PartExists (FileUri )) //this fails even though the file exists in the zip
throw new ResourceException(String.Format("Zip {0} does not contain file", BundlePath));
...
Is there anyway to still use the packaging system provided by .NET to read standard zip files, or do they need to be created using the library.
Edit:
Adding this file (Content_Types.xml) manually, and zipping using the Windows compression utility, proves to be successful in allowing the package to read.
Thanks.
System.IO.Packaging isn't there to read zip files but packages. Use DotnetZip instead.
Unfortunately I believe you are correct there isn't a good way to get the System.IO.Packaging libraries to open up any file in a standard zip format that doesn't contain that [content_types].xml file.
I was working on this issue a few months back, and this is what I was trying to implement something that would inject this file before we just decided to initially generate all of our files from within .NET:
the format of the zip file is the following
(---file 1---)(---file 2---)...(---file x---)(table of contents)
Without a third party library you should be able to open up a zip file as a binary file, hop to the end and read that table of contents, add a [content_types].xml file at the end with the types/default extension info, adjust the table of contents entries, append it to the end of the file, and go. The problem I was running into when trying to implement this is there are various checksums on the file to verify that it hasn't been corrupted, I hadn't gotten them all by the time I needed to change directions on this.
I'm sure this is more info that you needed, but should you decide to implement your own solution hopefully this helps.

Categories