I have designed and created two seperate windows application ( say winapp1 and winapp2). Winapp1 creates a file(say file.txt) in the disk containing some text. And I need to merge this file.txt with precompiled version of winapp2 ie winapp2.exe so that the winapp2 can display it.
Winapp1 creates a file with different contents each execution time. And for each file there will be a copy of winapp2 that needs to be merged.
Is there a way to this? If there is, help me.
And my English is not so good. Thanks for reading this.
The easiest solution, (assuming that releasing the source code for winapp2 to the system that runs winapp1 doesn't present problems) is to have the entire source for the winapp2 project accessible to winapp1. The source should include a blank copy of the file as an embedded resource. Winapp1 can then modify the source file and use MSBuild to build a fresh copy of Winapp2.
To modify the text file, you should be able to just use the normal file manipulation .NET methods and to call MSBuild, you may be able to do it via a .NET class, but you can certainly just call the msbuild executable from the relevant .NET framework folder in %windir%\Microsoft.NET\Framework\ and pass in the full path of the project file.
Related
So I want to create a C# application that can be transmitted to users which can then run an "exe" file copying the data files. Therefore, the application should contain at least to things:
The "exe" file
The files containing the data
The data in the application will be in most cases a directory with files and subfolders. My concern is how to store this data. I was thinking about storing the data in ".bin" files while being able to read the data with the exe file and place the files/folders in the correct structure, but I don't know exactly how would I do that with files and folders. Does anyone have any suggestions ? Is there a better way? Do you have any recommended reads ?
Thanks!
When you compile in either debug or release mode, there will be an .exe file in the bin/debug or bin/release folder for your project together with all the project files. You can move that to whatever machine with the .NET framework installed and run the .exe.
If you want to make an actualy executable, that's more difficult to do. Check out this post for more inspiration on that.
If your build is meant for distribution, better compile it on Release mode.
You will find the assemblies on your project_folder/bin/Release.
You may want to copy all contents in the release folder by compressing it, or better yet, using an installer compilation tool, like InnoSetup - http://www.jrsoftware.org/isinfo.php/, that is free and will do your application installer just fine.
I'm writing some integration tests for some SQL scripts that live in a folder separate from the project. Since the setup of the machine I'm writing on the tests on differs from the machine they will be run on, I would like to include them as resource files rather than hard coding any paths. However the default behavior for adding an existing file as a resource file simply copies the file, which is not what I want in case any of the SQL scripts get updated.
Does anyone know the best way to get the resource file to actually reference the SQL scripts that are in a folder separate from the project, or to somehow copy them into the assembly at compile time so I don't have to load them via absolute/relative paths?
Edit: For clarity, I'm trying to get the resource file to act as a symlink to the original file at compile time. Adding an existing file to a resource in file in Visual Studio simply makes a copy of the file, which means any changes to the original are not propagated to the resource file.
After asking on IRC, someone guided me to what I was looking for. You are able to add an existing file to a project as a link (there is an arrow on the Add box when in the file dialog), and set it's Build Action property to Embedded Resource
https://support.microsoft.com/en-us/kb/306234
Daniel posted a link on how to actually read an embedded resource:
How to read embedded resource text file
Is it possible to embed an exe file in a class library (dll file)?
I want to use this exe without the necessity of copying it manually to my workstation. In other words, if I want to use my C# class library in another app, I won't need to copy these exe files in a folder and pass the path of this folder in my app.
If there is a way how to do this, it would be great.
sorry but what I mean is just, I made a library for screenshots using Selenium Webdriver and when creating a new webdriver object, I need to pass the exe file of the webdriver.
what I need the most is that I don't want to copy the exe file if I will use this library to another workstation for example, I want everything to be packaged as one file
Thank you
Well, technically you can embed a binary file as a resource within a DLL (by adding the file as a binary resource through the project properties), but you'll still need to save the file to disk in order to execute it (which is assume what you're trying to do) and will possibly have security issues unless your application is fully trusted.
If the binary file is a resource you can extract the bytes from the static Properties class:
byte[] exe = Properties.Resources.MyExe;
and save it to disk like any other byte array.
If you own the code for the EXE then it would be a lot better for you to turn your EXE code into a library. Then you'll be able to refer to that library from anywhere and call any public functionnality it has. It's a far, far, FAR better approach.
Should you still need to run that code as a standalone process, nothing prevents you from making a new EXE front that will refer to that same library.
Now if you do not have the code, then depending on your deployment strategy you may prefer creating a reusable deployment component / module that can be attached to other application setups.
Is it simple or even possible?
Why: Following my other question and using this approach, now I would like to simply embed the source file to the resources so I can copy it to the temp folder while the application is running - and keep the application as a single file.
I assume using a pre-build event is the best way to do this. If so, how would it be done?
EDIT: I'm asking about adding it before building because I also assume it won't be automatically updated if I add it manually once and then change the code after.
I recently went through this same issue when developing an examples suite for a .NET control which had to display its own example source code in the application.
The approach I ended up with was as follows.
I created a batch script (run in pre-build) to copy all the code files under /Examples/* to another folder in the solution Resources/ExamplesSrc/*
I then included all these files under Resources/ExamplesSrc/* in the csproj and saved it.
The next step was I set all the files under Resources/ExamplesSrc/* as embedded resource and committed the change to SVN. I did not commit the examples (generated) to SVN, just the modified csproj and batch file.
The effect when developers checked out was that they had (!) icons on all the resources (they were not on disk, but the csproj was looking for them), however as soon as they built the generated files appeared and all was well. This approach also worked with a build server (Team city) and the examples suite can now load and browse its own code via embedded resources.
One caveat you should be aware of. There is a quirk (by design apparently) in VS2010. If an embedded resource has ".cs" in it (i.e. any code file!) it cannot be loaded from the assembly using Assembly.GetManifestResourceStream(). To work around this all source files were renamed in the batch copy step from *.Xaml.cs to *.Xaml.c.txt, from *.cs to *.c.txt
Hope this helps!
Turns out I don't need to (re)add the source file each time I build the solution!
When I add it manually once it becomes a "Text" file on resources - and I can easily access it as a string using Properties.Resources.SourceCode (having the file named "SourceCode.cs"). And yes, it is updated automatically since the resource property "Persistence": the file is linked at compile time.
I am writing a short batch file to prepare a control library DLL with Examples project for deployment via sip file and have the following question.
Given a csproj file at known location and a DLL at known location, is it possible to programmatically update the csproj from the batch file (via third party command line exe, or other scripting) to add the new DLL?
My folder structure is
/Build
/SDK
/WPF
/4.0 : ControlLibrary.dll sits here
/Examples
/WPF
/4.0 : Examples.csproj sits here
Assuming the batch file is at the /Build level, is there any way to modify Examples.csproj to reference ControlLibrary.dll ?
Just to clarify, the reason why I have the structure like this is I wish to deploy an examples csproj to ship with my control library. Examples.csproj should reference the obfuscated control library under SDK/. Examples.csproj also exists on dev trunk (where it has been copied from) and in the development solution it references output of ControlLibrary.csproj on non obfuscated form.
Essentially what im creating here is a folder structure to zip up and ship the ControlLibrary plus examples, hence, the need to update the reference.
Update - Solved using Powershell
Please see this related question and answer on adding and removing references using Powershell
csproj files are XML files - you can easily write a command line application to manipulate these files (adding, removing nodes etc).
You can call such a command line application from your batch file.
You can find the schema for this file at:
%windir%\Microsoft.NET\Framework\[framework version]\Microsoft.Build.xsd
As described in this SO answer.
I don't understand why you would need to modify the csproj file in your case. Just make sure the library reference in the csproj file is relative, i.e. ..\..\..\SDK\WPF\4.0\ControlLibrary.dll and it will keep working fine even if you move the complete folder hierarchy to a new location.
If you're trying to simplify adding the library to new projects though, take a look at NuGet. It's the best way for distributing and deploying libraries.