I would like to use ulink with C++ Builder XE2 to see if I can slim down the now ridiculous exe and dll size.
Has anyone gotten ulink to work with C++ Builder XE2.
Side note: DLL in XE was 1.6 MB in XE2 is now 3.0M.
I believe it is a drop in replacement.
Back up your old ilink32.exe and ilink32.cfg
rename ulink.exe to ilink32.exe and drop it in to $(BDS)\bin
check ilin32.cfg and make sure all the paths are correct for your project's needs.
Related
When using the C/C++ extension for Visual Studio Code with WSL, it will never refer to /usr/include/ unless you create a project file any time, as you have to allow it to create a local config file called c_cpp_properties.json. This means you simply cannot run standalone C files unless you create a workspace around it.
Is there some way to automate this, even a little? It's very annoying having to redefine my standard includes every time I reopen the program.
Ideally I would like to set this up such that I can just work with my C files standalone rather than as a project as I am frequently using university assets and it's very annoying to have to create a project to work with any demo they give me. I have looked everywhere but just can't find any kind of global setting where I can tell the extension to refer to /usr/include/ - with or without a local config file for the project.
Thanks
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 would like to debug an instance of a SQLite database created from modified SQLite code. As a user selects some data from the database I'd like to step through the SQLite source code and see what the logic of SQLite is. The purpose for this is I would like to see if I can add a SELECT trigger to the SQLite source code and create a SQLite database with my new type of trigger in it. Currently SQLite only supports triggers on UPDATE, INSERT & DELETE.
So far I've downloaded the "amalgamation" SQLite source code from http://www.sqlite.org/index.html and managed to build it in Visual Studio 2010. I have no idea how to debug against it however. I tried creating a test C# web application that used the SQLite project as a project reference - but it won't let me add it as a reference (Throws an error saying "A reference to 'mySQLiteproj' could not be added" which is SOOO useful). My current structure is simply an empty C project with the sqlite3.c and sqlite3.h files in it.
The SQLite code is written in C, which I am unfamiliar with, so maybe I'm going completely down the wrong path? I am coming from a C# background so please don't suggest I scrap using Visual Studio and instead use Notepad or some other "hardcore" IDE :)
In short: How do I debug SQLite Source Code?
Edit: I've added the shell.c file to the project as suggested by Sergey and can now "sort of" debug. It will hit breakpoints in shell.c, but not sqlite3.c. I can step into sqlite3.c as a function call from shell.c, but the lines don't seem to match up with what code is running. Half the lines are greyed out (by resharper perhaps?) and there is no auto-watch of variables or highlighting of which line the code is currently breaking on.
To debug library code written on a language you "unfamiliar with", it is better to start from the beginning.
Here the algorithm:
Learn language (C)
Learn your tools (debugger in Visual Studio)
Learn the target (SQLite - is library which provides API for others, so you need set breakpoints on SQLite API for example sqlite3_open() and "Run" shell.c source file in Visual Studio)
I've created cmake-based build for SQLite amalgamation so you can generate Visual Studio solution, build it as Debug target and then debug. Hope it will be useful.
I've recently installed resharper 6.0. It took my long time to set up everything as I wanted. Now I want to export all this settings to another computer. I've tried this aproach without any success (might be because the computers use different versions of visual studio?). Then I found this in this answer. But RSM works for r# 5. I started reading to see if there is going to be RSM for r# 6.0 and there will not be because in r# 6.1 some settings management options are included. But I'm stick with r# 6.0.. Is there any way I can transfer my settings from one PC to another?
Now you may want to update to ReSharper 6.1 where the management of settings are improved including an export and import feature.
You didn't explain what you meant by "without any success".
Were you able to find the folders and copy the files?
Were there files already in the target directory? (If there weren't, you probably had the wrong directory.)
Did you diff the old and new files as a sanity check? (This would be especially important since you're apparently expecting this to work even when the two machines aren't running the same version of Visual Studio. There could easily be differences in the file format across VS versions.)
Did you make sure to close Visual Studio before copying the files?
Did you just copy files in ReSharperVersion\VisualStudioVersion, or did you also copy the files in the vAny directory?
At any rate, if you really can't copy the global settings files, and if you can't install 6.1 (why not? it's a free upgrade from 6.0), I think your only other option is to export and import your coding-style settings by going to ReSharper > Options > Languages > Common > Code Style Sharing. That won't get all the ReSharper settings, but it will get some of the most important ones.
Suppose you have some source code that comes from the unix world. This source consists of a few files which will create a library and a lot of small .c files (say 20 or so) that are compiled into command-line tools, each with their own main() function, that will use the library.
On unixy systems you can use a makefile to do this easily but the most naive transformation to the windows / Visual Studio world involves making a separate project for each tool which, although it works, is a lot of work to set up and synchronize and more difficult to navigate at both the filesystem and project/solution level. I've thought about using different configurations where all but one .c file are excluded from the build but that would make building all the tools at once impossible.
Is there a nice way of building all the tools from a single "thing" (project, msbuild file, etc.)?
I'm really not interested in using cygwin's gcc/mingw or NAnt. I'd like to stick with the standard Windows toolchain as much as possible.
You don't HAVE to use visual studio to compile code. You can make your own batch file or Powershell script that simply calls the compiler on your source, just like a makefile.
So I've been looking into this for a while now and the solutions all leave much to be desired.
You can...
Create a lot of small projects by hand.
Use MSBuild and deal with its steep learning curve.
Use a build tool that does not integrate well with Visual Studio, like GNU make.
You can't even make a project template like you can with .NET projects! Well, you can make a wizard if you want to wade through the docs on doing that I suppose. Personally, I have decided to go with the "many small projects" solution and just deal with it. It turns out it can be less horrible than I had thought, though it still sucks. Here's what I did in Visual Studio 2008:
Create your first Win32 command line tool project, get all your settings down for all platforms and make sure it works under all circumstances. This is going to be your "template" so you don't want to edit it after you've made 20 copies.
(optional) I set up my paths in the visual studio project files so that everything is built in the project directory, then I have a post-build step copy just the dll/exe/pdb files I need to $(SolutionDir)$(OutDir). That way you can jump into a single directory to test all your tools and/or wrap them up for a binary distribution. VS2008 seems to be insane and drops output folders all over the place, with the default locations of Win32 and x64 output differing. Spending a few minutes to ensure that all platforms are consistent will pay off later.
Clean up your template. Get rid of any user settings files and compiler output.
Copy and paste your project as many times as you need. One project per tool.
Rename each copied project folder and project file to a new tool name. Open up the project file in a text editor like Notepad++. If you have a simple, 1-file project you'll need to change the project name at two places at the beginning of the file and the source code file name(s) at the end of the file. You shouldn't need to touch the configuration stuff in the middle.
You will also need to change the GUID for the project. Pop open guidgen.exe (in the SDK bin directory) and use the last radio button setting. Copy and paste a new GUID into each project file at the top. If you have dependencies, there will be one or more GUIDs at the bottom of the file near the source code. Do NOT change them as they are the GUIDs from the dependencies and have to match!
Go into Visual Studio, open up your main solution and add your tool projects.
Go into the configuration manager and make sure that everything is correct for all supported platforms, then test your build.
It's not beautiful, but it works and it's very much worth the setup time to be able to control your builds from the GUI. Hopefully VS2010 will be better about this, but I'm not too hopeful. It looks like MS is giving a lot more love to the .NET community than the C/C++ community these days.
If you have a makefile you can use a 'makefile' project in Visual Studio (which in misnamed - it simply allows you to specify custom build/debug commands), and use it to invoke GNU make.
You will need to change the makefile to use the VC++ command line tools instead of cc or gcc or whatever it uses, but often these are specified by macros at the top of the makefile.
If the makefile uses other Unix specific commands (such as rm), you may need to make modifications, or create bath files to map commands to Windows equivalents. Another option is to install any necessary tools from GNUWin32 to make it work.
If the build is very complex or involves configure scripts, then you have a harder task. You could generate the makefile from a configure script using MSYS/MinGW, and then modify it as above to make it work with VC++.
Makefile projects will not be as tightly integrated in Visual Studio however. All the build management is down to you and the makefile.
If you're really using Visual Studio, I would suggest creating a project for each tool, and adding these projects to a single solution. From Visual Studio, it's easy to build a complete solution all at once, and MSBuild knows how to build .sln files as well.
msbuild myslnfile.sln
or even:
msbuild
... will build your solution.