I have a predefined SQLite database and want to ship it with my App, so I can access it at runtime.
How do I achieve this?
Moreover, I want to Unit Test my app. So far the database file is referenced with the Unit Test Project as basis. Hence, my paths get broken.
How do I test a app like described above?
I've answered to the similar question at MSDN forum. It may help you.
I'm creating UWP app with SQLite.Net-PCL I already have a SQLite db
that I want to use (I do not want to create a new one in the app).
I've copied it to the root of my project folder. How do I access it?
https://social.msdn.microsoft.com/Forums/windowsapps/en-US/b6d7a970-0088-4bd4-aaa8-c86bca4387df/
Related
I want to clone an existing Firebase project, lets name it ProjectA that previously exists on Firebase console with some Remote Config data to another new project(without any Remote Config data), lets name it ProjectB.
The idea behind my question is that currently I have developed an Android app that is using the google-service.json(Firebase configuration file) file from the ProjectA, so I want to create/clone a new Firebase project ProjectB(NOTE: I don't want a new Firebase app on the same project) that starts with exactly the same Remote Config data from ProjectA and then add the google-service.json from the new ProjectB to my new Android app.
I have read the firebase-cli documentation but looks like it's out of its scope.
Has someone accomplished something similar like this or has an idea how can I accomplish this? Thanks in advance!
I just created this ruby gem to automate the manual process that I needed to do from a web browser for cloning my remote config data from ProjectA to a my new ProjectB.
NOTE: The gem is really an alpha version and just consider remote config without any rules. If some of you want to fork it and improved please feel free to do that.
There is currently no way (neither through the Console or through an API) to create a project that is a clone of another project. At the moment you will have to re-create the config data in the new project manually.
Firebase documents a flow to move data between projects here:
https://firebase.google.com/docs/firestore/manage-data/move-data
Though the method they outline requires a billed account.
Is there a way where the database references in a SQL Server Database project (Dacpac) can be derived at run time?
We're building a product which uses Dacpac to deploy database objects.
Our product implementation teams also use Dacpac projects by adding database reference to the product Dacpac file and then adding their own additional objects to the project.
The problem we're facing is - every time the implementation needs to point to a newer product release version, the parent dacpac references in the implementation dacpac have to be changed manually to refer to the new file path of the new product dacpac (in the newer release). We've mutiple implementation teams and multiple database projects in each implementation.
Is there any way the database references (*.dacpac) in a database project can be derived at run time using a variable or parameter or something of that sort?
My understanding of your question is as follows:
You have a SSDT database project (see example image below), that has a database reference (similar to #1 below) with stored procedures and other db objects that access the reference database (similar to file #2 and code #3). You've 'built' the solution resulting in a DACPac and now you want to take this DACPac and reference other databases at deploy-time. Hopefully I understood your question correctly.
If so, then you can use the Publish Profiles feature to achieve this (similar to #4 below).
The code for this can be seen in my notes from my SSDT talk github project.
If you look specifically at the demo04 solution file, you will see that I have a DEV_MJE.deploy.ps1 PowerShell file and a DEV_MJE2.deploy.ps1 file. These scripts run MSBuild to build the DACPac and then use SqlPackage to publish DEV_MJE.publish.xml or DEV_MJE2.publish.xml respectively. Note, if you run this example on your machine, you'll need to add MSBuild.exe and SqlPackage.exe to your path, as well as modifying the TargetConnectionString in the xml files to an existing development database.
As an example of how this works...When I use the Publish Profile DEV_MJE.publish.xml, the resulting GetDataFromAnotherTable.sql file contains:
SELECT [SomeData] FROM [AnotherDb_MJE].[dbo].[AnotherTable]
Whereas when I use DEV_MJE2.publish.xml the resulting GetDataFromAnotherTable.sql file contains:
SELECT [SomeData] FROM [AnotherDb_MJE2].[dbo].[AnotherTable]
Notice the database reference in the second has changed to AnotherDb_MJE2.
For a good description of how Publish Profiles relate to DACPacs and SSDT Database Projects, see this web page. It also contains information on alternative ways to deploy beyond SqlPackage.exe.
Something else to consider
Note, that using file paths to version control a DACPac is not really the best practice. Consider the DACPac artifact as similar to a .Net DLL. It is the biproduct of a build.
As such, a better approach is to use NuGet and tools like Octopus Deploy to store, track, and deploy DACPacs. See the stackoverflow answer for a good description of how this works.
Hope that this helps,
Michael
Thanks for the followup comment, I think what you are trying to do is when you write and deploy your code be able to use different dacpacs depending on the project?
Each implementation team might have a different version of the shared dacpac deployed so you can't just put the files in a shared location and call the dacpac "Product_Latest.dacpac" or something, so everyone always gets the latest version.
".sqlproj" files are standard msbuild scripts and references can be managed using msbuild properties so you can technically change the reference at runtime. If you edit your .sqlproj file and add a property in the first <PropertyGroup> tag, I used:
<ProdDacpacVersion Condition="'$(ProdDacpacVersion)' == ''">v1</ProdDacpacVersion>
v1 is the unique name for the version folder - you just need something to identify the dacpac you want.
I put the property just after TargetDatabaseSet and IncludeCompositeObjects.
If you then find the reference to the dacpac and instead of
<ArtifactReference Include="..\..\..\..\..\Desktop\prod\v1\Database2.dacpac">
<HintPath>..\..\..\..\..\Desktop\prod\v1\Database2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
Use the property from above:
<ArtifactReference Include="..\..\..\..\..\Desktop\prod\$(ProdDacpacVersion)\Database2.dacpac">
<HintPath>..\..\..\..\..\Desktop\prod\$(ProdDacpacVersion)\Database2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
Then the reference will use the property to get the path of the dacpac. There are a few ways you can set the property, you could edit the .sqlproj file when you want to take a new version of read the property from a file or environment variable or something (i'll leave the msbuild fun to you!).
I would, as a standard, everytime the reference was changed either reload the project or restart visual studio - it won't take long and it will save lots of cursing :)
When you deploy the dacpac's, the deploy looks in the same folder for references first so just make sure you copy the right one into the bin folder when you deploy.
I want to clone an existing Firebase project, lets name it ProjectA that previously exists on Firebase console with some Remote Config data to another new project(without any Remote Config data), lets name it ProjectB.
The idea behind my question is that currently I have developed an Android app that is using the google-service.json(Firebase configuration file) file from the ProjectA, so I want to create/clone a new Firebase project ProjectB(NOTE: I don't want a new Firebase app on the same project) that starts with exactly the same Remote Config data from ProjectA and then add the google-service.json from the new ProjectB to my new Android app.
I have read the firebase-cli documentation but looks like it's out of its scope.
Has someone accomplished something similar like this or has an idea how can I accomplish this? Thanks in advance!
I just created this ruby gem to automate the manual process that I needed to do from a web browser for cloning my remote config data from ProjectA to a my new ProjectB.
NOTE: The gem is really an alpha version and just consider remote config without any rules. If some of you want to fork it and improved please feel free to do that.
There is currently no way (neither through the Console or through an API) to create a project that is a clone of another project. At the moment you will have to re-create the config data in the new project manually.
Firebase documents a flow to move data between projects here:
https://firebase.google.com/docs/firestore/manage-data/move-data
Though the method they outline requires a billed account.
I have developed a lot of class library projects in VS 2012 to be used in Windows Forms and Web forms applications.
The question is simple. Do I need to deploy the DLL file itself together with the XML file that is created?
For example, the class library project is called DataWare. Upon building, I got 5 files in Release folder (this project reference Entity Framework):
DataWare.dll
DataWare.pdb
DataWare.dll.config
EntityFramework.dll
EntityFramework.xml
I know that ".pdb" file contains debugging information, so there is no need to deploy. The ".config" file is not taken into account. Instead the App.config or Web.config are.
Regarding this, I think I have to deploy just DataWare.dll and EntityFramework.dll.
However, the main doubt is if I need to deploy EntityFramework.xml as well.
Regards
Jaime
The XML file contains the doc comments for the public types & members in the assembly.
You only need it if you want Visual Studio to show documentation in IntelliSense.
If you're deploying a consumer-facing app (as opposed to a developer-facing reusable library), you do not need it.
No, in most cases you do not need it. If there is an external DLL that needs to be copied local and referenced using the config, then you might need to, but that is somewhat rare.
I have doubt regarding windows phone 8 application development. The database using sqlite for windows phone 8 is pre-loaded into the application or it should be created dynamically at the time of installation in windows phone..? and if it is pre-loaded then how to create the database.db file..?? and also if it is dynamically created, what is the procedure to create dynamically...??
I would say, pre-loaded into the application is the very common way.
Take a look at this article, I think the steps to accomplish your task are quite the same: http://wp.qmatteoq.com/import-an-already-existing-sqlite-database-in-a-windows-8-application/
The first step is to copy your database in to the Visual Studio project and, from the Properties window, set the Build action to Content.
Once you’ve done this operation, you’ll be able to access to the files embedded in your project thanks to the Package.Current.InstalledLocation object that is available in the Windows.ApplicationModel namespace.
The InstalledLocation’s type is StorageFolder, which is the base class of all the folders mapping in WinRT: for this reason, it exposes all the standard methods to interact with the storage, like getting a file or a folder. This way we can use the GetFileAsync method to get a reference to the database embedded into the project and, after that, using the CopyAsync method we can copy it into the local storage of the application. We can copy it in the root of the local storage (like in the following example) or in a specific folder, by getting a reference to it first using the GetFolderAsync method.
For those who are not able to work with sqlite I would like to suggest them to follow this link : http://dotnetslackers.com/articles/silverlight/Windows-Phone-7-Native-Database-Programming-via-Sqlite-Client-for-Windows-Phone.aspx and when you are dumping the data into the project .. you just need to change the properties of the "database1.sqlite" i.e. Build Action = resource . Thats all you need to do ..