I'm using PreEmptive Protection Dotfuscator for winform executable .exe file.
Do I have to add Map.Xml and Dotfuscator1.Xml to Setup Project with other Dependencies to locate it in Program Files/MyApp directory, or it is no needed?
(Disclaimer: I am a developer on Dotfuscator and am answering this as part of my job.)
No, after Dotfuscator has run and created a protected/obfuscated .exe file, you typically do not need to involve the Map.xml or Dotfuscator1.xml files in any later step of your build process. Your protected .exe file will be able to run without them, and they are not needed when building your setup executable.
In fact, these files contain sensitive information that could be used to undo parts of the obfuscation. Do not add these files to an installer project, packaging project, or anything that could potentially leave your organization. For details, including how to handle these files as part of your development process, see my answer here.
I have created a GUI and Database for my company. I am trying to alpha test the program. I made the program so that everyone would place it on their C drive so that the file paths would stay consistent. When I email the zip folder to everyone it adds an extra folder that is causing errors to the file path (I believe the error occurs during extraction?). Does anyone know a good way to prevent this from happening? Thanks!
Although "xcopy deployment" is a valid method to deploy programs, it can come with complications, as you have discovered. Instead, you can create an actual installer program which is much more versatile.
For a lead-in on making an installer you can read Create MSI installer in Visual Studio 2017.
Make sure that the program uses locations as given in the Environment.SpecialFolder Enumeration so that it is automatically adapted for any (properly-configured) Windows installation.
Other installers are available, e.g. Inno Setup, which may offer simpler or more detailed configuration of some options like replacing or keeping older files, or installing prerequisites like a required framework version.
I have to create one-file (.exe) program.
In this program user can choose directory from his computer.
I create program in order of http://www.tarnyko.net/en/?q=node/31 and it run well.
But when I invoke FileChoser (click on button) I got this error
GLib-GIO-ERROR No GSettings schemas are installed on the system
Response of Tarnyko to this issue is in coment on webpage - this is known "bug" with static compiling.
How can I work around this?
On the one hand I have to have one-file.exe.
On the other hand I realy do not want create "sophisticated" FileChooser on my own... is there any option to deal with this?
My ideas:
1 - Call native File chooser of OS (windows)
2 - Create file chooser on my own - if it is not "much hard" in gtk
I do not know how to do either of this.
Sorry for duplicating - probably succes solution is in answer form "ebassi" here GLib-GIO-ERROR**: No GSettings schemas are installed on the system (not tested yet)
Settings schemas (which are used in GTK in more places than just the file selector widget) cannot be statically linked into a binary: they have to be installed in a well known location (controllable via the $XDG_DATA_DIRS environment variable) and they have to be compiled into a cache.
GTK's dependencies like Pango and GDK-Pixbuf also use ancillary files and loadable modules that are not strictly compatible (unless you're willing to spend time on it) with static linking.
The usual recommendation for only providing a single executable for your application is to have a self-extracting installer that contains all the installed files necessary to running a GTK application, and avoid static linking.
I don't think it's possible to create just one .exe file (without any other files) with GTK+. Maybe only when you recode the GTK and it's dependencies - which is not an easy task to do.
The best solution I found is to put all schemas (and also icons for your GTK+ app) in the same location where your .exe file is placed:
EXE_LOCATION\program.exe
// For icons:
EXE_LOCATION\share\icons\hicolor...
// For schemas
EXE_LOCATION\share\glib-2.0\schemas
Then you deliver these files together with your .exe file and with all needed .dll files.
About the native file chooser in GTK+: It also needs the schemas - at least on Windows OS.
Which configuration management tool is the best for FPGA designs, specifically Xilinx FPGA's programmed with VHDL and C for the embedded (microblaze) software?
There isn't a "best", but configuration control solutions that work for software will be OK for FPGAs - the flow is very similar. I use Subversion at work and git at home, and wrote a little on 'why' at my blog.
In other answers, binary files keep getting mentioned - the only binary files I deal with are compilation products (equivalent to software object and executables), so I don't keep them in the version control repository, I keep a zipfile for each release/tag that I create with all the important (and irritatingly slow to reproduce) ones in.
I don't think it much matters what revision control tool you use -- anything that you would consider good in general will probably be OK here. I personally use Git for a sizable Verilog + software project, and I'm quite happy with it.
What will bite you in the ass -- no matter what version control you use -- is this: The Xilinx tools don't generally respect a clean division between "input" and "output" or between (human edited) "source" and (opaque) "binary." Many of the tools like to store some state information, like a last-run time or a hash value, in their "input" files meaning that you'll get lots of false changes. Coregen does this to its .xco files, and project navigator (the main GUI) does this to its .xise files. Also, both tools have a habit of inserting or removing lines for default-valued parameters, seemingly at random.
The biggest issue I've encountered is the work-flow with Coregen: In many cases, at least one of the following is true:
You have to manually edit the HDL files produced by Coregen.
The parameters that went into Coregen are stored somewhere other than the .xco file (usually in what looks like an output file).
You have to copy-and-paste the output from Coregen into your top-level design.
This means that there is no single logical source/master location for your input to the core-generating process. So even if you have the .xco file under version control, there's no expectation that the design you're running corresponds to it. If you re-generate "the same" core from its nominal inputs, you probably won't get the right outputs. And don't even think about merging.
I suggest CM tools that support version labeling and binary files. Most Software CM applications are fine with ASCII text files. They may just store a "difference" file rather than the entire file for updates.
My recommendations: PVCS, ClearCase and Subversion. DO NOT USE Microsoft SourceSafe. I don't like it because it only supports one label per revision.
I've seen Perforce and Subversion used in a couple of FPGA-intensive companies.
We use Perforce, and its great. You can have your code that lives in Linux-land checked in side-by-side with your Specs and Docs that live in Windows-land. And you get branching, labels, etc.
I've seen everything from Clearcase to RCS used, and it is really all okay for this kind of thing. The important thing is to get a good set of check-in policies established for your group, and make sure they stick to it.
And have automated nightly regressions. That way, when someone breaks the rules, they can be identified and publicly shamed.
I have personally used Perforce, Subverion, git and ClearCase for FPGA projects. Since VHDL and C are just text files, any works fine. However be sure to capture the other project and contraint files and any libraries you use.
Also think about what to do with the outputs, e.g. log file and bitstreams. Both tend to be big and the bitstreams are binaries.
Previously I used Subversion but have switched to git two years ago. Git handles FPGA design files just as well as it handles every other text and binary file. Git is all you need for version controlling your files and artifacts.
For building the designs, I recommend just using a single ISE project called "ise" (living in a subdirectory called "ise/"). You can take a look at my (very modest) FPGA open-source project on github for the file layout. I don't bother storing the ISE files at all since they are easy to regenerate. The only things I save are the Verilog files and some ISIM waveform config files. In other projects that use coregen I save the coregen.cgp project file and all of the *.xco scripts for regenerating cores. Then I use a Makefile for actually running coregen on the *.xco files. There are a few other Xilinx-specific files you should version control too: *.ucf, *.coe, *.xcf, etc.
I experimented with using Makefiles and the Xilinx command-line tools but found that ISE did a much better job tracking dependencies and calling the tools with the right arguments. Just don't make the mistake of trying to version control your ise/ project files or you will go mad. Xilinx has something like 300 different file types which change every release. If you want to save a file, you can try the ISE project file itself with a .xise extension. Anything that is hard to recreate, like the golden bitfile that you know works and took 6 hours to build, you might want to copy that and configuration manage it explicitly.
Whenever I start a new project, I have to go through setting up the debugger with Eclipse time and time again before I can use it. Isn't there a default setting for all new C projects I can change?
I'm not sure exactly what you mean by "setting up the debugger" (perhaps you can clarify), but under "Preferences -> Run/Debug -> Launching -> Default Launchers" you should be able to select your preferred launcher for different kind of launch modes. This can also be selected individually for each launch configuration.
Typically it is up to the toolchain and/or project to determine which debugger/launcher is suitable to use for that specific project, but I know there is a bug in CDT which prevents toolchains from properly specifying the default launcher to use.
I only use Eclipse for Java, so I can't give you an authoritative answer. But since no one else seems to be answering:
Java projects have a (more or less) hidden file in the project directory called .project and another one called .settings . I'm not sure if this would apply to the C environment as well, but it seems likely. You may want to look at the set of such "hidden" files for a well set up project and a virginal project side by side to find out which settings make the difference.
Given that information, you may be able to simply edit (perhaps with some assistance from a script you can write yourself) the file(s) in question to do the configuration textually without a lot of mouse clicking.