When I go to update my database I run $env:ASPNETCORE_ENVIRONMENT="Development" first before executing the Update-Database command to set the correct environment. If I had previously deployed changes to Test for example, running this command should point me back to my Development environment and no longer be pointing at Test.
Unfortunately this only works maybe 33% of the time. Every time I run this I also run $env:ASPNETCORE_ENVIRONMENT and check that it returns back the correct environment and it does. Then I run the Update-Database command that I need and it somehow changes back to the previous environment.
Anyone have any idea on either what I am doing wrong or a way to know that I will be connected to the correct DB? This could be very bad if the wrong database is hit and data happens to get deleted or a system goes down.
The way that I have worked around this for the past couple of years is to have a second terminal window (I use cmder so I can use a linux based command line environment) and use dotnet commands from there. So far I haven't had any issue doing this and don't have any faith in the package manager console.
Commands take the form of the following:
Set current environment set ASPNETCORE_ENVIRONMENT=development
Add new Migration:
dotnet ef migrations add MyNewMigration
Revert Migration: dotnet ef migrations remove
Rather than exporting the variable at command line, you should set/export the variables within the database update script. So if you are running a shell script, you can export via standard export commands. If you are running perl/python, you should update the environment variables within the script. That way, you will have consistent behavior.
Related
I have some changes to rescaffold my tables and create a migration named X. I try to apply X via update-migration but I have an exception about some of default data. My X migration is not in __EFMigrationHistory table because of the exception. However, when I run remove-migration command to remove X migration, dotnet try to run Down function in X. I couldn't understand why this happened.
I want to use remove-migration because to edit ModelSnapshot.cs file is hard manually.
Is there anyone who knows the reason?
I've found a solution. If the migration has a script related HasData function (InsertData(), UpdateData() or DeleteData(), that causes a trouble when you want to run remove-migration. I uncommented those lines and removed the last migration successfully.
I have created a CLR function in .NET and I am using that to deploy it to the database. When I try to generate the deployment script it errors out with the same error as when I try to deploy it. The error is :
publish DB_Name to ServerName
creating publish preview...
if this deployment is executed. [CLR.XmlSerializers] will be dropped and not re-created.
This deployment may encounter errors during execution because changes to [CLR] are blocked by [CLR.XmlSerializers]'s dependency in the target database.
It is trying to stop you from destroying data before you publish. Often in dev/test environments you don't need this safe guard. In the advanced options, disable the verify steps and publish again. This is assuming you're using VS or similar, but the end result should be the same, you need to disable the validation or change your script.
I am relatively new to this. I am trying to publish my asp.net web application to a production IIS server. In visual studio I select Filesystem based Publishing, since web deploy is not supported by that server.
I use Code First Migrations for my Databases. As long as it is the first time, or if I drop all my tables, the deployments to production work fine. However if I have existing tables with production data, I get the error below -
"The model backing the 'ApplicationDbContext' context has changed since the database was created. Consider using Code First Migrations to update the database"
How do I enable automatic schema updates when my model changes? I have "AutomaticMigrationsEnabled" my Configuration.cs set to true. Do I need to set something in my global.asax or Web.Config? What am I missing?
On my local server I can run Update-Database. How do I make this automatically happen in production whenever I push model updates?
UPDATE:
I was able to get rid of the error in production by following the steps in Using Entity Framework (code first) migrations in production
However I am not sure if this is the best way to fix the problem. Or if I wanted production to keep running this line every time the application starts.
Database.SetInitializer<ApplicationDbContext>(new
MigrateDatabaseToLatestVersion<ApplicationDbContext, Configuration>());
When you use MigrateDatabaseToLatestVersion it will indeed run your migrations for you. So you definitely need that or one of the alternatives like using DbMigrator in code or generating a script (update-database -Script).
These will run the migrations in your folder. The problem is you have AutomaticMigrationsEnabled = true in your configuration. This tells EF to just automatically update your database and does not create the code based migration file.
There are a couple of solutions. First, you could add a manual migration before you deploy (add-migration MyMigrationName) or you could switch your initializer to something like CreateDatabaseIfNotExists and then call the migrations in code as shown above.
See here for a detailed explanation.
So I've got an OPC-DA server in my program. When the user first runs the program or (even better) installs the program I want just one line of code to be run: myServer.registerServer;. And similarly when they want to uninstall the program it should run the opposite command: myserver.unregisterServer.
Now I'm guessing to do this I'm going to have to do something with a command line argument? maybe check to see if the passed value is equal to something and then if so I can register/unregister accordingly. Then if the passed value matches neither it just continues my program like normal. Issue is I'm not quite sure how to work this into the installer I'm using. Speaking of, I'm using Visual Studio Installer and using their 'Setup Project' project. Can what I'm asking for be done with this or do I need to make a separate installer. I've never had to do anything like this so any information you guys have is really appreciated.
The way you'd do this with a Visual Studio setup is to run the program as an install custom action with the command line that registers it, and an uninstall custom action with the command line that unregisters it.
Ideally you wouldn't run the program at all. Many (if not most) installation programs know what the required registry entries are and they add them to the registry entries that (in Visual Studio's case) are in the Registry view in the IDE. This data is typically always static and can be added to the system without running code.
I am currently trialling Visual Studio Online with an On-Premises build server. I have managed to move a number of projects into VSOnline but for some reason have hit a brick wall with one.
The project appears to build correctly but when I get to the end of the build I get the following error:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (4291): The command "copy *.dll ........\PROJECT NAME\bin\Debug /y" exited with code 1.
I have deleted the project and re-created to be sure there was nothing wrong with my initial setup. As far as I can tell I have followed exactly the same process to create this project as I have 2 others that have both worked perfectly.
When I take the MSBuild command that is actually executed and run that directly on the build server it works fine.
Is there any way to get more information about what is going wrong? Has anyone else come across something similar?
Switch your post build events to AfterBuild.
Always use properties instead of hard-coded names. E.g. use $(Configuration) instead of Debug or Release.
The Post Build events for several of the projects were causing the issue when building on TFS.
I added
IF "$(BuildingInsideVisualStudio)"=="true" ( copy command here )
to the Post Build Events so that they only run when building in Visual STudio and are ignored in TFS Build.