I have a WPF application that uses too many images and videos to set the Build Action as Resource, so I'm using Content instead. Is there a way that I can dynamically search those files the application was compiled with so that I can verify that all the files still exists on the computer at runtime? I'd rather not write up a file list that I have to constantly update when adding, removing, or renaming content files. Thanks!
In order to find so called loose content files in the runtime you should use Reflection and look for instances of AssemblyAssociatedContentFileAttribute attribute. This attribute is added automatically during build process of WPF application for every file with Build Action = Content.
To sum up, you can verify if your files exist on the target computer during the application startup in the following way:
public App()
{
var a = Assembly.GetExecutingAssembly();
var attributes = a.GetCustomAttributes<AssemblyAssociatedContentFileAttribute>();
foreach (var attr in attributes)
{
var path = attr.RelativeContentFilePath;
//Verify if a given path exists
...
}
}
Related
public void Save_Token(string _Token)
{
var Token_Location = #".\token.txt";
using (StreamWriter sw = new StreamWriter(Token_Location))
{
sw.WriteLine(_Token);
}
}
I tried to get the token from the api (json) and I deserialized and saved it. I would like to write to the file to save for later. But I want this application to be ran on anyone's PC. So I don't want to use the full path.
I also tried
Path.Combine(Environment.CurrentDirectory,Token_Location);
still nothing is written, unless I use the full path.
You can't guarantee that the current user has write access to the folder from where the file is executed. There is a special folder (APP_DATA) that applications are supposed to use when storing user data on a computer:
public void Save_Token(string _Token)
{
var tokenDirectory = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), "YourCompanyOrOrganizationName");
var tokenFile = Path.Combine(tokenDirectory, "token.txt");
Directory.CreateDirectory(tokenDirectory);
File.WriteAllText(tokenFile, _Token);
}
Your file will then be stored in a path like "C:\Users\yourusername\AppData\Roaming\YourCompanyOrOrganizationName\token.txt"
It is generally a bad idea to use a relative path in software source code because the "current working directory" of the process that the relative path is relative to can change over the runtime of the application.
Activities like showing a file open dialog or using a third-party component can unexpectedly change the current working directory so that it is dangerous to assume a certain current working directory.
I use unity3d and vs2019 to read a text file (txt) as follows：
public class MeshTest01 : MonoBehaviour
{
// Start is called before the first frame update
void Start()
{
string filePath = #"D:\Desktop\Unity\Mesh\77.txt";
string[] lines = File.ReadAllLines(filePath);
foreach (var item in lines)
{
Debug.Log(item);
}
//List<string> planesStr = TxtOperation.GetFaces2str(linesStr);
//Debug.Log(TxtOperation.GetFaceIndex(planesStr[0]));
}
}
The error information is as follows：
DirectoryNotFoundException: Could not find a part of the path "E:\project\GitHub\RobotSimulation\***D:\Desktop\Unity\Mesh\77.txt".
Why does the previous part of the file path appear
Honestly, I can't explain why this happens.
Usually yes, this would be one way of how to read an external file.
My guess would be that since your file is placed on a different drive the project might be sandboxed and therefore interprets the path as a relative one. Never tried to load files from different drives to be honest.
However, in general I would keep the files together with the project they belong to and place them
either in the Application.streamingAssetsPath in the editor in the folder Assets/StreamingAssets for files that shall be
read/write able for the editor
but readonly later in a build
or the Application.persistentDataPath for builds if you want to
write to them via code
or let the user change the content
externally afterwards
Then you would get your path using
var path = Path.Combine(Application.streamingAssetsPath, "SomeFolder", "77.txt");
or accordingly
var path = Path.Combine(Application.persistentDataPath, "SomeFolder", "77.txt");
For the streaming assets there are some special cases (e.g. on Android) where you need to read the file using UnityWebRequest.Get since it gets compressed.
Alternatively if it is an option for you you could also directly drag it into the Assets (or any folder below except special ones like StreamingAssets, Resources etc) and then directly drag it into a field via the Inspector using it as a (read-only) TextAsset
[SerializeField] private TextAsset meshFile;
and later access it's content via
var lines = meshFile.text.Split('/n');
Also I general: You should make a huge circle around the Resources!
Unity themselves strongly recommend to not use it! This and the reasons can be found in the Best practices.
How can I bundle a folder with a one click application and reference those files/folders after?
Seems rather simple but I just can't figure out how.
As in, I had the file index.html in the folder UI and I wanted to package that with the application, then I want to get the stream for that file with the string "/UI/index.html" but instead of just index.html, an entire website.
Add the folder to your VS Project, right-click on it and select "embed as resource". That will make the files in the folder be embedded in the .NET assembly. To get the file contents in your program, you can use something like this:
public class ReadResource
{
public string ReadInEmbeddedFile (string filename) {
// assuming this class is in the same assembly as the resource folder
var assembly = typeof(ReadResource).Assembly;
// get the list of all embedded files as string array
string[] res = assembly.GetManifestResourceNames ();
var file = res.Where (r => r.EndsWith(filename)).FirstOrDefault ();
var stream = assembly.GetManifestResourceStream (file);
string file_content = new StreamReader(stream).ReadToEnd ();
return file_content;
}
}
In the above function I assume your files a text/html files; if not, you can change it not to return string but byte[], and use a binary stream reader for that.
I also select the files by file.EndsWith() which is enough for my needs; if your folder has a deep nested structure you need to modify that code to parse for folder levels.
Perhaps there is a better way, but given the content is not too large you can embed binaries directly into your program as a base64 string. In this case it would need to be an archive of the folder. You would also need to embed the dll used for unzipping that archive (If I understood correctly you want to have single .exe and nothing more).
Here is a short example
// create base64 strings prior to deployment
string unzipDll = Convert.ToBase64String(File.ReadAllBytes("Ionic.Zip.dll"));
string archive = Convert.ToBase64String(File.ReadAllBytes("archive.zip"));
string unzipDll = "base64string";
string archive = "probablyaverylongbase64string";
File.WriteAllBytes("Ionic.zip.dll", Convert.FromBase64String(unzipDll));
File.WriteAllBytes("archive.zip", Convert.FromBase64String(archive);
Ionic.Zip.ZipFile archive = new Ionic.Zip.ZipFile(archiveFile);
archive.ExtractAll("/destination");
The unzipping library is DotNetZip. It's nice because you need just a single dll. http://dotnetzip.codeplex.com/downloads/get/258012
Edit:
Come to think of it, as long as you write the Ionic.dll to the working directory of the .exe you shouldn't need to use the dynamic dll loading so I removed that part to simplify the answer (it would still need to be written before you reach the method it is in though).
I am having an xml file like:
<CurrentProject>
// Elements like
// last opened project file to reopen it when app starts
// and more global project independend settings
</CurrentProject>
Now I asked myself wether I should deliver this xml file with above empty elements with the installer for my app or should I create this file on the fly on application start if it does not exist else read the values from it.
Consider also that the user could delete this file and that should my application not prevent from working anymore.
What is better and why?
UPDATE:
What I did felt ok for me so I post my code here :) It just creates the xml + structure on the fly with some security checks...
public ProjectService(IProjectDataProvider provider)
{
_provider = provider;
string applicationPath = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
_projectPath = Path.Combine(applicationPath,#"TBM\Settings.XML");
if (!File.Exists(_projectPath))
{
string dirPath = Path.Combine(applicationPath, #"TBM");
if (!Directory.Exists(dirPath))
Directory.CreateDirectory(dirPath);
using (var stream = File.Create(_projectPath))
{
XElement projectElement = new XElement("Project");
projectElement.Add(new XElement("DatabasePath"));
projectElement.Save(stream, SaveOptions.DisableFormatting);
}
}
}
In a similar scenario, I recently went for creating the initial file on the fly. The main reason I chose this was the fact that I wasn't depending on this file being there and being valid. As this was a file that's often read from/written to, there's a chance that it could get corrupted (e.g. if the power is lost while the file is being written).
In my code I attempted to open this file for reading and then read the data. If anywhere during these steps I encountered an error, I simply recreated the file with default values and displayed a corresponding message to the user.
I've created a custom configuration section using XSD. In order to parse the config file that follows this new schema, I load the resource (my .xsd file) with this:
public partial class MonitoringConfiguration
{
public const string ConfigXsd = "MonitoringAPI.Configuration.MonitoringConfiguration.xsd";
public const string ConfigSchema = "urn:MonitoringConfiguration-1.0";
private static XmlSchemaSet xmlSchemaSet;
static MonitoringConfiguration()
{
xmlSchemaSet = new XmlSchemaSet();
Stream xsdStream = Assembly.GetExecutingAssembly().GetManifestResourceStream(ConfigXsd);
XmlReader schemaReader = XmlReader.Create(xsdStream);
xmlSchemaSet.Add(ConfigSchema, schemaReader);
}
}
By the way my resource is: MonitoringConfiguration.xsd. And the namespace of the other partial class (that represents the code behind of the .xsd file) is MonitoringAPI.Configuration.
The problem is situated here:
Stream xsdStream = Assembly.GetExecutingAssembly().GetManifestResourceStream(ConfigXsd);
The xsdStream is null, so I guess the resource can't be found! But why?
Thank you
The name of the resource is always:
<Base namespace>.<RelativePathInProject>.<FileName>
So if your resource is located in "Resources/Xsd/", and your default project namespace is "MonitoringAPI.Configuration", the resource name is:
"MonitoringAPI.Configuration.Resources.Xsd.MonitoringConfiguration.xsd"
Also make sure the build action for your resource is set to "Embedded Resource"
Easy and correct way to get the actual name of your embedded resource:
string[] resourceNames =
Assembly.GetExecutingAssembly().GetManifestResourceNames();
Then simply check resourceNames array, and you will know for sure what to pass to GetManifestResourceStream method.
In my case,
When you try to access the file via GetManifestResourceStream(). You will get an error due to invalid path of the file, and stream will be null.
Solution:
Right click on the file which you have added in to solution and Click on Properties.
Select the Build Action as Embedded Resource. (Instead of Content - by default)
By default, visual studio does not embed xsd file therefore you must ensure "Build Action" property of xsd file is set to "Embedded Resource" to make it works
just add your resources under form1.resx -->add existing items
double click on the resources you added under Resources folder.go to properties and select "Embedded Resources" instead of none.
Then
try debugging the line:
string[] resourceNames=Assembly.GetExecutingAssembly().GetManifestResourceNames();
check the resources you added are in the array. then copy the resource name exactly from this array and try putting the name on your code..it works fine!!
You can get the Resource Stream by passing the Resource Names which is as follows below...
Get the resource name e.g..
Assembly objAssembly = Assembly.GetExecutingAssembly();
string[] strResourceNames = objAssembly.GetManifestResourceNames();
Pass the Resource Names to ...
Stream strm = objAssembly.GetManifestResourceStream(strResourceNames);
Now you have Stream you can do whatever you want...
In my case, it was something completely different:
My UWP App compiled correctly in Debug and Release configuration but GetManifestResourceStream returned Null only Release configuration.
The issue was, that in the UWP Build Configuration file (and only there) the setting "Compile with .NET Native tool chain" was enabled. After disabling, GetManifestResourceStream worked as expected.
I had an issue where I was embedding a whole heap of .xsd files in many different assemblies; everything was working (GetManifestResourceNames was returning the files I'd expect to see) except for one. The one which wasn't was called:
Something.LA.xsd
I wasn't dealing with specific cultures and the .LA bit at the end of the filename was being picked up by the compiler as this file being for the LA culture - the filename in the manifest was going in as Something.xsd (under culture LA) - hence me not being able to find it (it ended up in a satellite assembly). I dodged the issue by renaming the file - presumably it is possible to explicitly state the culture of a given embedded resource.
Actually, a quick google reveals:
How can I prevent embedded resource file culture being set based on its filename
According to this answer, you've got to do hacky things - so perhaps renaming the file wasn't so bad after all :)