My desktop app includes a SQLite database it uses internally. The contents of this database are stored in .SQL (text) files so that the entire DB can be recreated from scratch based on the source files. Running these scripts in the correct order is what I refer to as a "database build" in this context.
I am looking for ways to integrate this DB build into a Visual Studio solution. The ideal might be:
DB build is automatically re-run during a solution build whenever any .SQL file has changed, or if the target database does not exist
IDE integration - edit .SQL files right there inside VS2015
External program sqlite3.exe needs to be called to process each .SQL file
The output database file is deposited in the Debug\bin folder (or Release) just like any other build output
Processing errors captured in the Output pane
In other words - it behaves like a standard C# or C++ etc. project and build.
The only way I have turned up so far to do this might be to create an MSBuild script / project file. That may work but is not necessarily more advantageous than just running a batch file, and seems like it would lack IDE integration.
I was hoping there might be an existing VS project type which would accommodate this, but if it exists I haven't figured that out.
Build a SQLite database from Visual Studio?
If I understand you correct, you can include your database file in your project. Set the type to Content and CopyToOutputDirectory to Copy if newer, that will make sure the file is copied to your output directory and you can edit .SQL files inside VS2015.
Unload your project and add following into the project file .sqlproj:
<ItemGroup>
<Content Include="test.sql">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
See the similar thread for some more details.
Hope this helps.
Related
We have two projects in visual studio, first one is workflows which generated sql files by a DSL tool (this is something like Linq2Sql designer which gestates files automatically by every change)
Second one is a Database project,
I want to include the generated sql files in database project, so that when the content regenerated, I wouldn't need to copy paste it in database project.
For this reason, I add existing sql files as Link (Add as link) to database project, the problem is they don't copy in build process, then I get an error about files are not exists.
I found an article about it in http://mattperdeck.com/post/Copying-linked-content-files-at-each-build-using-MSBuild.aspx but that one is not working for me too.
Then I was thinking about including files automatically in my solution by adding something like , but they will be added to the root of the project not in the desired path.
<ItemGroup>
<None Include="..\..\Workflows\*.sql" />
</ItemGroup>
I solved my issue, but I keep it open to get better solutions
I added below code to project file
<Content Include="..\..\Workflows\*.sql">
<Link>Deployment\Post-Deployment\WorkflowDataSync\%(Filename)%(Extension)</Link>
</Content>
And I added this to pre-build event command line in project properties page
xcopy "$(ProjectDir)..\..\Workflows\*.sql" "$(ProjectDir)Deployment\Post-Deployment\WorkflowDataSync" /Y /I
In Visual Studio 2010 through 2013, by default (eg. When I create a new Console Application) new solutions output their compiled executable into Solution name/Project name/bin/Debug/. I want them to be output into Solution name/Debug/, and likewise for all other build configurations like "Release".
I can do this by manually going into properties of each project, going to the Build tab, changing Output path from bin\Debug to ..\Debug. I must repeat this for every project and every build configuration.
After dozens of solutions, I'm a bit sick of doing this tedious task by hand every time. Is there a way to change the default output path?
A solution that works for Visual Studio 2013 is sufficient.
This property is defined in each Visual Studio Project Template
So, for example, the C# Console Application template is located in
\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates\CSharp\Windows\1033\ConsoleApplication\consoleapplication.csproj
The csproj is an XML file that you can edit at your will. The build output directory is define like this (for each configuration):
...
<OutputPath>bin\Debug\</OutputPath>
...
<OutputPath>bin\Release\</OutputPath>
...
If you change this file, it will change all your future new C# Console Application projects. You could also write a utility program that list all csproj in \Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates and update them accordingly.
This is not necessary.
One of the projects in your solution is marked as the Startup project, shown in bold in the Solution Explorer window. An EXE project, like your console mode app. You used Project + Add Reference to add references to other projects in the solution so you can use the class libraries that those projects generate in your console mode app.
Those references will have the Copy Local property set to True.
When you build your project, MSBuild will automatically copy the assemblies from their respective bin\Debug directory into the bin\Debug directory of your console mode app, thanks to that Copy Local setting. And it is smart enough to also look at the dependencies of those class libraries and copy them as well.
So after the build is complete, the bin\Debug directory won't just have your console mode project's EXE file but also all the DLLs it needs to execute properly.
There are a few ways that this can go wrong and MSBuild cannot figure out that such a dependency actually exists. Pretty uncommon, you'd for example have to use Reflection in your code to load assemblies (Assembly.Load() and friends). The workaround for that is to explicitly copy the dependency in a post-build event. You didn't leave enough bread-crumbs in your question to judge whether that's the real problem.
What you ask for is certainly possible, the IDE just doesn't make it easy because it wasn't designed to assume this was necessary at all. You'd have to replace the Build + Output Path setting to, say, ..\Debug instead. You can create your own project template with that setting already preset. Create a new class library project, change the setting and use File + Export Template to create the template. You'll have it available the next time you create a project.
But, really, find out first why the default Copy Local machinery isn't working for you.
Rather than changing a global, protected file, you can create your own .targets file that changes the <OutputPath> however you want and import that into your projects. This could also set other defaults you might want to change and don't want to do for every project. All you'd have to do then in your project files is add something like toward the top (after the root element, of course):
<Import Project="$(SolutionDir)\Common.targets"/>
I am working with a VB 6.0 project. The project uses the packaging and deployment wizard. Where are deployment scripts saved when you use this wizard?
The deployment script is normally saved as a file alongside the project file with a .pdm extension.
The setup itself is created in whatever folder you told it to along with the support files required to rebuild the cabinet file.
To edit the deployment script, you can use a simple text editor like Notepad, or you can just re-run the wizard. I believe it uses the existing script as a base (but it's been ~10 years since I last used it).
I am working on an big old project. MSBuild is used as the build engine. And I see a lot of .proj, .bat, .sln and .csprj files used in the build process.
I know that .sln file and .csprj can be edit relatively easily with Visual Studio. But is there some easy way to help write and comprehend the .proj and .bat files?
Also, I am lost in the numerous environment variables such as $(SolutionFolder), where can I find the definitions for them?
Many thanks...
The following description is based on how I made use of such files in the open source project, http://code.google.com/p/lextudio/source/browse/#svn%2Ftrunk%2Ftrunk
.sln and .csproj should never be manually edited unless you are asked to. They should be mainly maintained by developers via Visual Studio.
Your focus should be put on the .proj file, where custom targets and properties are set. They are usually manually created and calling MSBuild to build .sln/.csproj in an expected way.
You can edit .proj files inside Visual Studio, as VS knows it is a MSBuild script type.
.bat files are usually wrappers over the core .proj file, so as to let you execute a certain target with expected properties, so it may only contain a call command to MSBuild.exe. I usually use Notepad++ to edit such files, as n++ provides highlighting for .bat files.
Many of the predefined properties are documented by Microsoft, as the link posted by #mortb shows.
.bat files are batch files. They cointains script that are executed by the windows command prompt. Each row contains a statement (like copy, execute program etc) that could be entered at the command prompt. I usually edit bat files in notepad, you may also edit them as text in visual studio. The windows help contains more information about batch files.
.proj is a generic Visual Studio project file
Finding a reference to the variables wasn't too hard:
http://msdn.microsoft.com/en-us/library/c02as0cs.aspx
Hope this helps
I have several Visual Studio web application projects that include SVN externals. When a new file is added to an external module, VisualSVN brings it down to the file system, but doesn't add it to the Visual Studio project; it has to be manually added.
I might write a macro to automate this process, and I'm wondering if I can make it a one-step process by either:
Having the macro initiate the VisualSVN update, then do the work (Q: Is it possible to trigger a VisualSVN update from a macro?)
Hooking into a hypothetical "post-update" event from VisualSVN to fire a macro to do the work (Q: Does such an event exist?)
I assume you are currently working like this: your "external modules" are just a loose collection of source files without a project file. Whenever a source file is added, you update all your application project files by adding the new source file, so that it is compiled into all the application assemblies.
I think you are doing it wrong. Your project solution file should contain a reference to a separate visual studio project file for each external. Each source file should be compiled into exactly one assembly.
For example, you might have a C# library shared between multiple web applications. This library has its own .csproj project file, which lives in the external location. If a source file is added to the library, the .csproj is updated. The updated .csproj file is then pulled it via an svn:externals declaration when you update your project.