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.
Related
I added some C# code to SQL project. For the first build and deployment it went smoothly, however after the second run of build/deploy I noticed that the CLR was ammended on SQL server side even there was no changes to C# code.
Is there a way to have make the build to generate the same binary each time it builds assembly from C# code if there was no changes in it? As I would like to have CLR code changes to be deployed only if there were changes made to C# code, not the each time the build creates new and different binary for the assmebly.
only if there were changes made to C# code, not the each time the
build creates new and different binary for the assmebly.
Does the assembly indicates xx.dll? If so, as I know for C# code, msbuild call the CoreCompile target to compile the C# code to output assembly. And the CoreCompile target will execute and create new assembly only when part of the input files are newer than output files.
According to your description, it seems the build engine will create new assembly even there're no changes made to the input source file for CoreCompile target, I suggest you change the Msbuild build output verbosity(Tools=>Options=>Project and Solutions=>Build and Run) to Detailed and check the build out log:
Then you can find what are the input files for the target(Ctrl+F to find the target) in your current datebase project. And locate the cause that the build engine always create new assembly in your machine.
I am extremely new to programming and have found that a good majority of my mentors use Visual Studio to code in C.
I would like to get an early start using SAMS C Programming.
Can anyone please tell me how to create a .c file in VS 2017? I am only able to create a .cpp file at this time.
Thanks
What you most likely actually want to do is create a project. Go to File-> New-> Project. Most likely, the first programs you will write are console applications (meaning they appear on that screen that resembles an old computer monitor, or what some computer screens look like when booting). If you want to create a console application, go from Project to Visual C++-> Windows Desktop-> Windows Console Application. Ignore any additional pop-up windows and just keep clicking continue. A file called main.cpp will automatically be generated. This is the file you will want to use for your code examples (but DO NOT DELETE the #include "stdafx.h" line, even if your example code does not have it).
Visual Studio compiles both .c and .cpp files as C++ by default. C++ has nearly everything that C has, but may take longer to compile when dealing with huge projects. If you want to use strictly C with no C++, then go to Project (a separate project tab on the same toolbar as the file tab -- it isn't within the file tab)-> ProjectName(Your Project Name) Properties-> Configuration Properties-> C/C++-> Advanced and select "Compile As". You should see a square with a upside-down "^" in it. Click that and select "Compile as C Code (/TC)". The "/TC" is just what you would type in if you were using command-line arguments instead of the convenient window that appears for you to modify everything. Finally, rename main.cpp to main.c.
Since you're learning C, I would also like to mention that I started making a C tutorial on my web site (and if anybody else also happens to see this post and the tutorial, criticize the tutorial as harshly as you can in the comments below).
Click on File, Choose Project --> Visual C++ --> Windows Desktop and under Windows desktop Choose Windows desktop wizard and give project name in the bottom then click on OK. a pop of Windows Desktop Project will come, check empty project and uncheck all options.then click on OK after that in the right side along with your project name more options will come..right lick on source file-> add -> new items -> choose c++ plus file but in bottom give file with extension .c..and you are done .enjoy coding
If you are truly interested in learning to program in C, then leave the VS Code IDE for later and learn to Build C/C++ code on the command line. VS provides a reasonably good compiler (cl.exe) and pre-configured command line (command prompt) windows to build both 32 and 64 bit applications.
The benefit to using the command line is learning what the compiler options are and what they actually do. Simply open a VS command line window and type cl /help. The compiler will list all options along with a short description. There are a great number of resource for command line building that can be accessed through the link above.
A second benefit is you can rapidly compile all your beginning C examples without worrying about projects, etc.. Just cl /nologo /Wall /Ox /Foname.o /Fename.exe /Tc name.c and you are done. (you will want to suppress unneeded warning with individual /wdXXXX options where XXXX is the warning to suppress) 50 Times faster than using the IDE.
Once you are proficient in using the command line, you will have a much easier time transitioning to the IDE -- because you can properly configure the IDE with the appropriate options for your build and you will know what the IDE is doing under the hood (or should be doing under the hood)
how can I use the Visual Studio Debugger on existing C programs I found in a textbook? I want to debug these little examples one by one, but without the overhead of creating a full project for each example.
Example: Let's say I compile "helloworld.c" from the Visual Studio command prompt ("cl.exe helloworld.c"). This gives me helloworld.obj and helloworld.exe. I would like to know if there is a way to use the VS debugger on "helloworld.exe". So far, I have only worked with the debugger on full-blown projects; I have no idea how to debug small "stand-alone" test programs without the Visual Studio project overhead. (I hope this is not a dumb question, as the VS Debugger might only be available for the full project.)
Thank you for any ideas.
Why don't you create one project for testing the sample codes? You can create a single .c-file for all the samples. This would look something like
void sampleA()
{
//hello world
}
void sampleB()
{
//hello everybody else
}
void main(int argc, char** argv)
{
// sampleA();
sampleB();
}
What I do when I have to use VS is to reuse the plain.c project I created a long time ago.
Just paste new code there and go. Throw the code in another file if you want to keep it.
If you're set on not using projects then you can do this. It just gets more difficult as the number of code files increases.
First, to do any meaningful source-level debugging, you will need to generate debug symbols. Add the "/Zi" switch to your cl.exe command line:
cl.exe /Zi helloworld.c
This will generate helloworld.exe, helloworld.obj, and helloworld.pdb (these are the debugging symbols).
Next you will open Visual Studio 2010. Use File -> Open -> File... and select helloworld.exe. It will generate a wrapping solution with one project for your EXE file.
In Solution Explorer, right click on the EXE file and select Debug -> Step Into new instance.
It should pop up a source window and show you the first line of your program. Now, debug away!
The debugger is part of Visual Studio, so you'll have to start it up anyway. However, for the debugger to work properly with your source code, you need to also generate a PDB file (see here). You get this by including /Zi or /ZI as argument to cl.exe (see here).
It is not impossible, but you'll have to learn a lot more about how to exactly build a program from the command line to get the best debugging experience. There are a bunch of options that are real time savers and greatly improve the odds that you'll discover bugs.
Which is a little beside the point right now, learn C instead of spending time learning a boring tool with way too many options. Creating a new project takes 5 seconds after a wee bit of practice. Use the Win32 Console Application project template.
One small setting you have to change if you want to compile as C instead of C++. Right-click the project, Properties, C/C++, Advanced, Compile As = Compile as C Code.
The "overhead" is hardly more effort that it took to post this question!
Simply start with the "Empty Project" template and add the single source file you wish to debug by right-clicking on the project browser sources folder. It takes mere seconds.
I have a C++ application which connects to a MySQL server.
It all works fine.
Currently it uses libmysql.dll.
At build time I link to libmysql.lib.
As far as I understand I can link to mysqlclient.lib instead and get rid of the dependency of libmysql.dll, i.e have the functionality embedded within my exe.
My question is: Where can I find the source to build mysqlclient.lib ?
When debugging the app when it's linked to mysqlclient.lib and stepping into mysql_library_init() for example the debugger (VC++ 2008) asks for the file "f:\build\mysql-5.0.67-winbuild\mysql-community-nt-5.0.67-build\libmysql\libmysql.c".
Note: libmysql.lib & mysqlclient.lib are included in the installation of MySQL.
IIRC, it's a part of the MySQL source code: http://dev.mysql.com/downloads/mysql/#downloads
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.