In order to include any file in the WEC7 we have to use the bib files.
In my case I created a subproject in which I wrote an application, now I want this application to be included in the run-time image. So I opened the project.bib file and wrote the following entries.
As it is an executable file, it should be in the MODULES Section
MODULES
Subproject2.exe $(_FLATRELEASEDIR)\Subproject2.exe NK
When I loaded the image on the device, I checked the Windows folder for the image, it was not present.
But when i wrote this in the FILES section
FILES
Subproject2.exe $(_FLATRELEASEDIR)\Subproject2.exe NK
It is present in the windows folder, may I know the reason?
Is it that for executables we have to keep it in the FILES section?
Or whether I'm doing anything wrong?
The MODULES section is for exe's or dll's that you may want to execute in-place, that is, without first loading them into RAM. Modules listed in this section will not be compressed in the final nk.bin image.
The FILES section on the other hand is for files that can be compressed in the image without affecting the ability to run in-place. This includes resources like bitmap images, audio and video files, and, perhaps surprisingly, also .NET exe's and dll's which are not real executables in this context (they are always loaded into memory before execution).
So generally, unmanaged/non-.NET executables should be placed in the MODULES section.
When you make changes to the .bib file be aware that, depending on the BSP, you may need to perform a platform sysgen and copy files to the release directory before generating the image.
In Platform Builder 7.0, this is done by right-clicking the Platform name in Solution Explorer and hitting Sysgen(SysgenPlatform...), followed by a trip to the Build menu and the Copy Files to Release Directory command.
You'll need to do the same if you change any .reg, .dat or .db files.
Notice that you can load the nk.bin file directly in Platform Builder to inspect its contents, files, registry entries, etc. This can potentially save some time compared to installing the image in the target. Just go through the File menu, Open, File... and navigate to the nk.bin file.
Related
I'm new to godotengine and want to make a project and upload it on github. I just get confused that those *.import files which are created automatically on adding a new assets and *.tres files which we make to save our tileset maps or something else are needed to be uploaded?
thanks.
Keep them. Include them in your version control system. They are text based (basically INI files) and fairly small, and so play well with version control.
*.tres files
The *.tres files can - and often exist - without a file that was imported. If an *.tres file is missing… You are screwed.
and *.tres files which we make to save our tileset
It is not mandatory to use the "save" option on your TileSet. If you add a TileMap, give it a new TileSet and save the Scene, the TileSet is saved in as part of the scene file.
Saving it to a *.tres file will allow you reuse it (on different TileMaps, potentially on different scenes). And it also means it can be modified independently (which is good for version control).
Once you saved it to a *.tres file, that file IS your TileSet, it describes what sections of what textures is what tile. As I said, if the file is missing, you are screwed. You would have to do that again.
What tile is placed where is part of the TileMap data, part of the scene.
*.import files
There a partial here: Godot: what are .import files, and should you commit them to git?. I'll elaborate further.
The *.import files include import configuration (what you set in the Import panel). Know that they must exist along side the imported file. If an .import file is missing Godot will re-import with the default settings (which is not good if you changed them) and recreate the *.import file.
It is also worth mentioning that the *.import files reference files in the .import folder (.godot/imported in Godot 4.0). But there is no need to include that folder. It is a read only cache, it contains duplicates of the resources in a binary format convenient for Godot (and thus not good for version control). With the original file and the *.import file, Godot reconstructs it.
See Files generated on the import process:
Importing will add an extra .import file, containing the import configuration. Make sure to commit these to your version control system!
I am processing a big images dataset and I'm trying to reorder the files in classes, while at the same time keeping the original directory structure.
To do this, I make a second directory structure with symlinks to the files in the first one.
Everything works as it should but for one small detail: the symlinks created via os.symlink() do not show the image thumbnail, while if I make a link of the same file (e.g., via right click & send to Desktop) I do see the thumbnail.
I wanted to check how the two link files differ (note, the link files themselves, not the linked file), but if I try to drag the os.symlink-generated file in a text editor it opens the linked file instead (while this does not happen with the .lnk file generated via right-click).
What's the difference between the link files? Is os.symlink making something different than a .lnk file? If so, is there a way to get the thumbnail? And if there's no such way, how can I make a .lnk file instead?
I have a Visual C++ for Linux project in VS2017 that I'm building on a Raspberry Pi running Raspbian. This project consists of a single source file (main.c) and an image (test.jpg). When building the project, I want the image file to also be deployed to the pi, so that the code in main.c can do something with it locally. However, I can't figure out how to do this
The image file's Content property is set to True, as is Included in Project. In the project properties, under Copy Sources, Sources to Copy is set to "#(SourcesToCopyRemotely)" and Copy Sources is set to "Yes". However, when I build, only main.c is copied to the Pi, and the compiler output is just a single .out file. I hoped to also see test.jpg there, but alas.
This article mentions that #(SourcesToCopyRemotely) defaults to all files in the project. However, when I evaluate the value of #(SourcesToCopyRemotely, it evaluates to just "main.c".
How do I make sure content files in my projects also end up in the build directory, along with the .out file? Preferably without having to manually enter each filename in a post-build step.
It turns out this is a bug in VC++ for Linux. A workaround, currently, is to use Additional Sources to copy. There's a caveat though: it doesn't work with remote paths that start with ~. So you can't use $(RemoteRootDir) if the Remote Build Root Directory setting is set to the default of "~/projects".
I've currently got Remote Build Root Directory set to "/home/pi/projects" and for each file I want to copy to the build directory I set Additional Sources to Copy to "[filename]:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$Configuration)/[filename]". For instance:
firstimage.png:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$(Configuration)/firstimage.png;secondimage.png:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$(Configuration)/secondimage.png
Right-clicking on the non-source code file to open it's properties page and flagging as Content in the General tab will cause the file to be copied to the remote. There is no need to add anything to the Copy Sources tab. The Copy Sources page of the project properties must show the default of #(SourcesToCopyRemotely). And when you edit this setting the macro should show an expansion with the additional files included.
I have found that it necessary to refresh the macro by clearing Source to Copy and then restoring it to the default after you have marked the additional files as content.
I have encountered problems when the additional files are not in the same folder as the C++ source files on the Windows host and/or you want to put them somewhere else on the remote. There are several open issues on the VCLinux GitHub site like this one so it will be worth reporting any problems you have on there.
[VCLinux 1.0.6 on VS Pro 2017 + Debian Jessie remote]
The "Pre-Build Event" section of the project properties offers "Additional Files To Copy". Addressing my file there (relative to the solution) showed following in the output when building:
Copying file 'C:\myfilepath\resource.png' to '/home/pi/projects/myproject/resource.png'
It is possible to move the files to the final destination then with Remote Post-Build Events (mv source destination). Not the most elegant way, but the first thing I got working..
we actually build an InstallShield project for our application with the functionality to include files dynamic into a component. All files will be taken which are in a specific place.
Because of problems, which are not part of this question, we want to change this to components where we add files explicit to custom separated components.
The question is, is there a best practice for this? We have the small fear that we easily can forget to add files to the component we new created. These can be dll files, .config files, pdfs or just xml.
(We build the installer every night using TFS.)
We found a solution for the problem.
What we wanted to solve:
During the build we want to be informed if files got removed
During the build we want to be informed if new files are missing
we solved this by two more or less easy things.
1. Information if a file is removed
This is easy sone, we have all files added explicitly, each single file is an own component now, if one file is missing the whole project does not build with the exact error message.
2. Information for missing files
For this we wrote a small tool which runs by a prebuild event of the installshield project.
There it opens the *.ism file as an xml file and searches for the "Files" table.
Than it takes all files from the drop folder and looks if all files are in there.
If there are files missing but we don't expect them, like pdb files or test dlls, we have an additional text file we just called "IgnoreList".
The tool skips these files by the check.
Now we are on a very good state to get informed directly on the next morning if the project was able to build or not, and if not what happened, so we can be sure that in the final target application are files are there :-)
I'm trying to get my website to talk to a friend's program. Think ITunes - one main program with hundreds of thousands of little things installed into it. We don't want to have to create an InstallShield install program for each of those hundreds of thousands of little things.
We have the files grouped into the folder sub-structure.
We have a .REG file for what registry entry needs to be added to see the new folder group.
But is there a way to do a self extracting zip file that reads a registry entry so we know where they installed the original program to be able to dump the new files there as well? I want them to double-click the EXE and click Finish and for everything to work.
(I've been looking into INF and CAB files through IExpress.exe, but haven't found the answer. I remember Package for the Web didn't have an option to read a registry entry, but did let you modify the suggested install path.)
Thanks so much.
Best wishes,
Andrea
But is there a way to do a self extracting zip file that reads a registry entry so we know where they installed the original program to be able to dump the new files there as well? I want them to double-click the EXE and click Finish and for everything to work
Well, yes and no. There are self-extractors that can run a program after extracting all files. DotNetZip, for example, can produce an SFX which can do this.
Just an aside: a normal SFX is just a zip file, with a "stub" executable merged with it. The stub exe can do anything it wants to do, but the most basic thing it does is extract the files in the zip. When you use DotNetZip to produce an SFX, it embeds its particular stub into the zip. That stub knows how to extract files, and also knows how to invoke a program after extracting. You can also produce your own stub that can do other more exotic things.
So you could use an SFX for your purpose. When run, it would extract, then invoke it's extra program. The program could look in the registry, then move or relocate the extracted files to the appropriate place. Then terminate.
For a different twist, the SFX might have just two files: the program-to-run (the one that reads the registry, and another embedded zip. Then when the SFX runs it generates 2 files. Then it invokes the program-to-run, which reads the registry, then unpacks the contained zip and puts the files into the desired place.
Ok, so you could do it.
Should you?
mmm, maybe. This really is an installer, so, you should decide whether you want to use a zip as an installer. Don't forget, if you use an SFX as an installer, there's no good way to uninstall.
Have you tried Inno Setup toolchain? It's a bit better than a bare Self-Extracting ZIP file, it's a setup creation utility. I'm convinced it has got something to put some entry in the Registry, look also at the plugins.
Basically, a self-extracting executable that alters the registry, it's a setup program. So why don't you go for a proper one?
Website: http://www.jrsoftware.org/isinfo.php