When deploying a database theme to create a new QBO3 database, the Entity view was not created.
My theme includes references to the following .sqlproj projects:
Standard
Mortgage
Credit
Debt
And I see that the Standard.sqlproj > Scripts > Script.PostDeployment.sql includes creation of an Entity view if it does not already exist.
Do I need to deploy each project separately?
To include pre-and-post deployment scripts from "core" projects, modify your theme's pre-and-post deployment script to include the relevent scripts from the other projects.
For example:
:r ..\..\Standard\Scripts\Script.PostDeployment.sql
:r ..\..\Mortgage\Scripts\Mortgage.PostDeployment.sql
Note that the :r syntax is a SQLCMD convention to include external files. The included files will be run in the order in which they are included.
Related
Let's say I have a class that extends DBContext (hereby called DBContext for simplicity) defined in a shared library plus an extension method to simplify adding this DBContext to dependency injection (given a configuration variable, it will generate a connection string to the database).
How would I go about applying the database schema? From the shared library? From a binary that consumes this library?
It's my understanding that when you apply a schema to a database a migrations folder is created and I want one canonical place where these migrations go.
If I run dotnet ef database update from the shared library, how does it know where the database is if I'm not providing configuration? Where would I provide configuration (like which database server and what credentials)
This shared library will likely be used by many consumers, so having migration scripts on each project sounds like a bad idea. Any suggestions?
Place the Connection String inside configuration for your Startup project (appsettings.json or other) and pass it to your extension method in your library.
Leave the Migrations in the library project with the DbContext. When you run dotnet ef database update you can provide separate --project (the project with your DbContext and Migrations) and --startup-project (the project that actually consumes your library) options.
https://learn.microsoft.com/en-us/ef/core/cli/dotnet#using-the-tools
The startup project is the one that the tools build and run. The tools have to execute application code at design time to get information about the project, such as the database connection string and the configuration of the model. By default, the project in the current directory is the startup project. You can specify a different project as startup project by using the --startup-project option.
I did a build publish to a mvc applications and See that packages.config is also deployed even though i did select "Only files required to run this application" in the properties. Can i safely remove this nuget package list file using wpp targets when deploying ?
Yes you can remove it from the deployed application.
It is used by NuGet to keep a record of what NuGet packages are installed in a particular project.
By default, the build process copies all files from source to the destination directory. To exclude the file, right click the file, select properties and for Build Action choose 'None'.
Using EF6 and Database First, I created custom T4 templates (*.tt files) in my VS2013 class library project. I don't want to migrate the app.config file with my assembly so I delete it. When I Update Model from Database, it presents me with a connection to select (I believe this is stored in the Visual Studio user preferences). If I choose not to store this in the app.config, it continues to show this step in the Wizard. Whenever the connection selection step is presented and the wizard completes, I notice the EDMX generates the two default *.tt files alongside my custom ones. Any way of preventing this? I read an article about EF code-based configuration and I tried DbConfiguration.SetDefaultConnectionFactory but that didn't help. The EF wizard always wants a connection in the app.config. Is there any way around this?
I ended up leaving it in the app.config (on my machine) and do not migrate this file to our development/test/prod environments. It's become a manual task to confirm each app.config file since it has become necessary to migrate some files due to adding project assembly redirects.
We have a RCP application which includes domain specific configuration files(properties file, and few folders containing xml's) in its installation directory. We have provided update support through P2 framework which works for plug-ins and features, But now we are planning to provide update support for the configuration files as well.
Is it possible to update the configuration files with P2 framework?
Any link to do the same would be helpful.
What you need is the so-called "root files" (do not mix up with "root IU").
An example of those is org.eclipse.equinox.executable feature which includes the .exe/.so files which are installed to the root directory of your product.
There are several ways to achieve it, here the simplest one:
create a feature project named xyz.feature
place all files you want to have in the root of your product into the /xyz.feature/root.files/ directory
create the following entry in the /xyz.feature/build.properties:
root=root.files
Include this feature in your main feature / product configuration
Export the feature/product into a p2 repository
You can examine the resulting p2 repo to see what p2 does exactly with this magic "root=" property key on export.
I created a test project using a web.config file by renaming it to same name as the project, copying it to the bin folder and setting the Configuration File Name of the NUnit GUI runner to the name of my config file. Now I want to add more assemblies to this project but the problem here is each assembly has it's own web.config file.
How can I set the configuration files for the assemblies because I need to get my connection strings from these config files and considering when loading multiple assemblies they need to be in the same directory
While I feel that using config files for NUnit tests is a no-no (it's an integration test, in that case, I assume), there are various approaches you can try:
Put all your different connection strings under web.config in the connectionstrings section, with different keys. Access them via the System.Configuration classes.
For each project or DLL you can add an app.config file where you can store assembly specific information. This will be renamed as ProjectName.dll.config once compiled. Again you can access the contents of this file using System.Configuration
Create a new assembly that simply loads all these connection strings from a single file. And then access this assembly
If you are loading different web applications into the same directory (as you're saying you're accessing web.config files -- which means web applications) then you're making your life difficult. Each application has to have their own folder and virtual directory, and a web.config specific to only that application.