I'm planning to use Sqlite but I don't know how to integrate it to visual studio or use it. Any help please... thanks.
I really recommend using System.Data.Sqlite ( http://sqlite.phxsoftware.com).
Have been using it for quite some time and it works great every time! You can create tables using the designer, similar to for MSSQL etc. Recommended++
Depends on how you want to use it. The easiest is to get the amalgamation version - this version "contains all preprocessed C code combined into a single source file", meaning you have a single .h and .c file to add to your project. This is the officially recommended practice.
If you want to build a "proper" library or link against SQLite dynamically, you have a bit more work ahead, since there's no VS project/solution files included with SQLite. You'll have to set up your own library project, add the correct files from the sqlite-source-x.y.z.zip file, and set this project as a dependency on your main project. Doing this is actually officially discouraged.
EDIT:
Forgot to mention that the above solution is assuming C/C++, as OP didn't specify language.
use System.Data.Sqlite
System.Data.SQLite is an ADO.NET provider for SQLite.
Related
I've been working on a VS Code extension that uses Roslyn's workspace API to load a project, at the moment the extension supports .NET Core's old project.json format via the ProjectJsonWorkspace type in the Microsoft.DotNet.ProjectModel.Workspaces package.
With the new tooling changes being released soon I'm keen to support the new .csproj build format but can't appear to find a .NET Standard compliant workspace that supports it.
My understanding is that as it's using MSBuild, I will need to use the MSBuild (Microsoft.CodeAnalysis.MSBuild) package, however it does not support .NET Standard at this moment in time.
What is the best solution if one exists, or will I have to look at creating my own workspace implementation?
Having spoken with various people it appears that there is no .NET Standard compatible MS Build workspace, this can be seen by this answer below to the following GitHub issue:
We haven't done the work to make MSBuildWorkspace work properly with the new MSBuild cross-platform. In the meantime, you might look at what omnisharp does to populate it's workspace.
So it seems that at the time of writing if you want to target the MSBuild workspace in a .NET Standard compliant project then you'll need to build your own custom workspace using Roslyn's workspace API, this is exactly how OmniSharp do it.
Update (16/10/2017):
Whilst MSBuildWorkspace does still not support .NET Standard, there is a library called Buildalyzer that works cross-platform and will generate an AdhocWorkspace for you, allowing you to achieve the same goal.
using Buildalyzer.Workspaces;
// ...
AnalyzerManager manager = new AnalyzerManager();
ProjectAnalyzer analyzer =
manager.GetProject(#"C:\MyCode\MyProject.csproj");
AdhocWorkspace workspace = analyzer.GetWorkspace();
The same library will also allow you to reference a solution file too.
I want to use SQLite as a database for my C++ project. I also need the ability to password protect the database. I got the standard SQLite from SQLite.org working - but I need to password/encrypt the database and they don't do that - they just stub the interface for it to be done with
SQLITE_API int sqlite3_key( sqlite3 *db, const void *pKey, int nKey);
After researching on the web how to do this, I came across System.Data.SQLite. It claims to do all I need quite easily, but I need to do it from unmanaged C++ project in Visual Studio 2008. I tried their project - but I can't get my unmanaged C++ project to allow the DLL to work - it squawks about dll not being safe/clr:safe compile - which I can't set in the System.Data.SQLite project and compile.
Can anyone help me with this or point me to a good resource on how to do this? I have been thrown into a C++ project (hadn't touched C/C++ since college (97-98), so I am really struggling with this when it comes to the linker/libs/modules. Java and .NET have spoiled me!
Thanks,
Mike
You can't use a managed DLL from unmanaged code like that, they're different systems. Just use the normal unmanaged SQLite build and read the docs on how to use keys.
Recently, I've faced a similar problem like Mike and resolved it.
I would like to post my solution here in case anyone need.
I have two programs:
One is in C# to create encrypted sqlite database files using System.Data.SQLite.
The other one is in C++ to read the file created by the C# program.
After googling with no result, I looked at source code of System.Data.SQLite to figured out how System.Data.SQLite encrypts a database file.
I recognized that System.Data.SQLite uses SQLite.Interop.dll wrapping native sqlite with additional features such as encryption.
Therefore I used that native source code to build a static library. Then I use the library to read the encrypted database files.
You can find the source code at the following link:
https://github.com/OpenDataSpace/System.Data.SQLite/tree/master/SQLite.Interop/src
Update 2020/04/11
You can find a step by step guide at the following link:
https://wordpress.com/post/nguyenduyanhsite.wordpress.com/71
I know there are a lot of places where I can find sqlite data types such as in this link or this other link.
Maybe this question sounds stupid when I mention version 4 because version 4 documentation is not out there on the internet or maybe I have not been able to find it. Why is it that the dll library that I downloaded from SQLite site has:
also when I downloaded that library from here (sqlite-netFx40-setup-bundle-x86-2010-1.0.79.0.exe) and install the visual studio plugins I am able to create sqlite databases in visual studio as:
Note that I have several data types!!
I am very confused on the versions of sqlite. Am I using sqlite version 3? What are the data types that I can use with the version that I downloaded from here? If I am using sqlite version 3, then why does the visual studio table designer for sqlite gives me different data types than the ones from the documentation?
Seeing as there's no such thing as SQLite 4.x (yet, anyway), you're definitely using SQLite 3.7.10. The v4.0.30319 almost certainly refers to the .NET runtime, not SQLite.
SQLite has only a few built-in types, but ADO.NET has an interface to conform to, so this adapter does its best to map the set of types you see to SQLite's (much smaller) set of native types.
Is there a tool or some general approach to packaging all the files of an ASP.NET application into binary form to prevent modification once its deployed? I am thinking there would be a set of signed binaries and a config file for settings that we allow the customer to modify. Has anyone attempted this, is it even possible?
I would pay a reasonable amount for a slick commercial product that did this with minimal hassle.
UPDATE
Sorry, from the answers I can see that I wasn't clear. I meant literally packaging ALL files, not just the code files. This means aspx, scripts, images etc. I'm not trying to prevent reverse engineering... this is a supportability issue, i.e. to avoid dealing with problems brought about by customer messing with the files.
If you made a web application project than you can compile your code into a single dll file. You can find it in the bin folder.
Just use aspnet_compiler.exe to precomple everything and then use aspnet_merge.exe to roll up all of the compiled assemblies into a single assembly. You can use an obfuscation tool like DotFuscator if you want to make it more difficult to reverse-engineer. Visual Studio pro and up include a "lite" edition of Dotfuscator that you can use for this.
Your codebehind files will be compiled in a single dll as ZippyV already mentioned. The aspx files will get deployed normally on the webserver.
But still, your dll files can be disassembled quite easily. So to be sure you have to use an obfuscator.
If you mean ALL files including the aspx you could also consider ngen. It precompiles everything into a dll so you can't even get at the aspx pages.
Although, ngen was designed to get rid of the JIT compiling feature of the framework and is definitely not a generally recommended approach but it may work in your case well.
From VS2008 select the menu option "Tools" and then "Dotfuscator Community Edition". You will have a "Learn More" link after it starts up.
I also sign mine using SN.exe to make it have a strong name. Given all this, I think it is complicated enough to figure out a system if you are given the source code and help.... so I don't worry about it anymore.
maybe Dotfuscator your customer won't be able to modify it nor reverse-engineer it :)
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.