I am working with a MATLAB project, and would like to be able to configure variables and paths without re-creating the executable (currently done by using MATLAB's built-in deploytool). I realize I can create a simple text file, listing key=value pairs, and read that in during run-time. There doesn't seem to be any built-in support in MATLAB for creating configuration files that follow a standard format.
Are there any standard existing ways to use configuration files for MATLAB-generated executables?
1) Add your resource to the package in DeployTool in the shared resources part
2) Read by using:
fullfile(ctfroot(),'config.txt');
Edit : That is suitable if your configuration is "private", that is the user should not edit it. In this case it is deployed together with your program as a resource. If you want a "public" config for the users, I know of no better way than to do what you offered.
Related
I made a game in Godot and exported it in release mode in Desktop as exe file.
But, it also created a .pck file and a highscore.data file.
I want to create it as an installable application and I don't want the highscore file in front.
What can I do? I also want to publish it.
I am new in Godot and this is my first game.
Installers are usually wrappers, aside applications that extract the main app to specific directory. Godot doesn't provide functions to create one. If you really need installer, you can write one or just generate with tools like NSIS, Inno Setup and others...
Separate .pck file can be embeded by enabling "Embed Pck" option in export settings.
Screenshot
I'm not sure what highscore.data file is, but it looks like something creating from code. Use user:// prefix (like user://highscore.data) for file paths to create them in app_userdata directory (more in docs).
So if you use this two options, you will get a single .exe file with game.
I am using Serilog in my UWP application. I can write the log in App LocalState folder without any issue.
But now I want to write the logs in D: drive specific folder. I have added the broadFileSystemAccess restricted capability and enabled the full access from the settings.
But still it is not creating the file in the specified location and not raising any error.
Anyone know the fix for this? Thanks in advance.
var file = #"D:\Logs\Serilog.txt";
Serilog.Log.Logger = new LoggerConfiguration().WriteTo.File(file).CreateLogger();
There is a very important information about broadFileSystemAccess capability on the File access permissions document. I'm not sure if you note it.
This broadFileSystemAccess capability only works for APIs in the Windows.Storage namespace.
This point is very important. So, your issue actually is you need to check the LoggerConfiguration().WriteTo.File(file).CreateLogger() relevant method if it write to files by using the Windows.Storage APIs.
By my checking, it uses the StreamWriter method to write to files. But this method is not included in the Windows.Storage APIs. So, the issue was very obvious. You need to submit this issue to Github and let the officials to modify this method and make it work in UWP.
Or, if you're interested in serilog-sinks-file source code, you could download it and make the change by yourself, Then, you could compile a custom serilog library version for your UWP project.
MSI database contains set of tables, and I can successfully enumerate File table, which has all deployable file' meta-deta. What I need to extract is the actual contents of those files. msiexec, lessmsi, 7-zip all can do it, but I couldn't find any source/API to do it.
What I've discovered it that all other (resource) files are in Binary table, and Data field can be used to get content of those files (like icons, custom DLL etc).
Further, I found and know that Media table contains information about the .CAB file (MSI has all content embedded with <MediaTemplate EmbedCab="yes"/>. This simply means the CAB file contains the actual content. I probably need to read contents from "Structured Storage" of the .msi file.
How to extract the contents of CAB/MSI file, using native C Msi* functions?
Phil has given you the easy/simple answer but I thought I might give you a little more information since you've done some research. Checkout:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372919(v=vs.85).aspx
This is where the structured storage is. You'll see something like Disk1.cab as the Name (PK) and binary data. The data is a CAB file with the file entry in the cab matching the File.File column. From there you can use the File.FileName column to get the short name and long name (you'll want the long name no doubt) and do a joint to the Component table to get the directory table ID.
You'll also need to recurse the directory table to build the tree of directories and know where to put the files.
Fun stuff. There's some libraries in C# that make this WAY simpler. Or just call msiexec /a as Phil says. :)
The most straightforward to extract all the files to some location is to install the product in "advertised" mode. If you do a:
msiexec /a [path to msi] TARGETDIR=[some folder]
you'll see what happens.
In C++ call MsiInstallProduct () with that command line.
You have gotten many good answers already, including the use of dark.exe from the WiX toolkit. By downloading the WiX source code you should be able to get the code you need ready-made from there. I assume you may already have done this.
Chris has already linked to the DTF code you can check, but here is a link directly to dark.exe as well: https://github.com/wixtoolset/wix3/tree/develop/src/tools/dark. I would try both. This is C#, you seem to want native.
UPDATE: Before I get to the Win32 features you can use, check out this little summary of the C# DTF features: How to programmatically read the properties inside an MSI file?
Native Win32 functions: The database functions to deal with an MSI file can be found on MSDN (this is to deal with the MSI file as a database). There are also MSI Installer Functions (used to deal with the MSI file as an actual installer).
You can certainly find good examples of native code for this with a good Google search. Have fun!
BTW: It would help with a description of the actual problem you are trying to solve as well as what you need technically. There could - as always - be less involved ways to achieve what you need. Unless you are writing a security software or malware scanner or something super-involved.
And so it is clear: WiX's dark.exe fully decompiles MSI files into WiX source files and the resource files used to build them - you can then text and binary compare the various types of content (text compare for tables, binary compare for binaries, etc...). The process to do so via command line is described in the following answer: How can I compare the content of two (or more) MSI files? (this is about comparing MSI files, but one option to do so is to decompile them - see section on dark.exe - just for reference for others who find your question).
I like to link things together so we can find content easily at a later point in time. Strictly speaking it doesn't seem necessary here, you have what you need I think but others could perhaps benefit from some further links. Here are some related links:
Extract MSI from EXE.
What is the purpose of administrative installation initiated using msiexec /a?
How do I extract files from an MSI package? (explains why you should not use 7-Zip to extract).
I am currently trying to create a plugin-like library for my company.
I need to check if four directories exist within the project structure. As java.io.File is not available, I am pretty confused on how to check for existance of a file that needs to exist within the project structure?
The concrete use-case.
There will be four directories:
/entities
/converter
/attributes
/caches
Now if the developer uses this library and wants to access all, lets say "Person"-Entities from the server, he should be able to call
RestGet.getAll("Person");
and the library looks in the source directory of the project if there are these Files:
/entities/PersonEntity.java //<-- Stores the actual data
/converter/PersonConverter.java //<-- Converts the JSON answer of the server to the Object
/attributes/PersonAttributes.java //<-- An enum that is used to set the attributes of the object
/caches/PersonCache.java //<-- A simple Cache
How can I do this? I tried with FileSystemStorage, but it only tell me that I should use getAppHome()...
I don't quite understand the usage of the source directory which obviously won't exist on the device where your application is running.
You can get access to files in the root of your SRC directory which get packaged into the JAR using Display.getInstance().getResourceAsStream(...).
The replacement to java.io.File is FileSystemStorage which is covered in the developer guide.
I can't find a way to use the source server tools from the Debugging Tools for Windows on a static library project,
which is built separately from the solutions actually using that library:
The output of "ssindex.cmd" always displays "zero source files found" for the PDB file generated for the library
(using compiler options /ZI and /Fd).
Running "srctool.exe -r" on this PDB displays nothing, which probably means that the PDB file does not contain any source file information.
Running the same command on the PDB file of a test application which is also build as part of the the same solution
yields a list of all expected source files.
Is there a way to use source indexing for a static library project when it should be built seperately from the solutions using it?
Thanks for any suggestions!
You can use the "/Save" and "/Load" options to store and load source information for a static library, respectively. Using these options allows you to store information for your library and then later import it when indexing a project that links against your library.
When indexing your library solution, you specify the "/Save" flag with a directory in which to store index information about the library's source files. For example (assuming you are using Subversion for source control),
ssindex.cmd /System=SVN /Save=c:\source\libproj\srcinfo /Source=c:\source\libproj /Symbols=c:\source\libproj\Release\*.pdb
When later indexing your project that includes your library, you specify the "/Load" flag with the directory containing the library's source file information. For example,
ssindex.cmd /System=SVN /Load=c:\source\libproj\srcinfo /Source=c:\source\binproj /Symbols=c:\source\binproj\Release\*.pdb
There are two potential issues that may affect your ability to use this technique. First, it appears that some source control providers may not support saving and loading source control information. I know that the Subversion provider does and it looks like the SourceSafe provider does, but I haven't checked any others.
Second, this technique appears to only work for one external static library out-of-the-box. There does not seem to be a way to load information from multiple directories and the scripts currently overwrite the contents of the directory each time you use the "/Save" option. You could probably edit the source control provider module to append to the files in the save directory rather than overwrite them, but I have not tried it.
Also, note as you mentioned above that you only need to do this if your library is being built as part of a separate solution. If the static library is part of the solution you are indexing, its source files will be included if they are in the path specified by the "/Source" option.
It probably means you haven't inputed the correct directories when running "ssindex" so for ssindex you need to have: /source=C:/SourceCode/ /symbols=C:/SourceCode/bin/Debug I'm not sure if the "source" has an upper case S or not but that should be it!
when run svnindex.cmd, it always tell you "zero source files found"
after a painful diggin into svn.pm (the perl module to deal with svn), i found that:
first, svn.pm invokes "svn info -R $SourceRoot" to get all version info of files in $SourceRoot (passed by /source option),
then svn.pm stores all files in a dictionary which using the local file path as key
svnindex.cmd call srctool -r to get all source files info in *.pdb, and use the source file name as a key to query info saved in step2
the problem is:
svn.pm uses relative path, but *.pdb uses absolute path, so you will never find a svn log info for any file, then "zero source files found"
fixup:
change svn.pm line 162:
$LocalFile = lc $1;
to
$LocalFile = $SourceRoot . "\" . lc $1; #make path absolute