When development is finished and TFS (VSTS) takes over. The build completes successfully and the artifact directory contains the published website via a build definition. The Release Manager is then triggered, and takes over and creates a website in an environment, the website files are copied to the environment and the website started. All good so far.
Missing the Database migration steps here...
Now someone starts the server and it fails because the database has not been migrated. How do we do that? The EF Tools were not copied to that environment, in fact we can't even run dotnet.exe because the core sdk has not been deployed onto that environment either. so even if we had the tools, we can't execute them.
In EF 6.x it was easy cause we could just copy migrate.exe as part of the artifacts, and run that on the environment after the files were copied. As I understand it, the EF Tools are now a DLL (ef.dll) that has to be run by dotnet.exe. Does this mean that all web servers now need Core SDK to perform migrations?
Other details about my project setup:
asp.net.core application being deployed onto a QA server for testing. This is not a dev box, does not have VS2015 installed, does not have Core SDK installed.
Update: EF.EXE is part of preview3 and 4.
This solves the requirement for "dotnet.exe" being installed. I can copy that into the artifacts drop like I used to with migrate.exe. Is this the proposed solution by the EF Team?
EF.EXE is part of preview3 and 4.
This solves the requirement for "dotnet.exe" being installed. I can copy that into the artifacts drop like I used to with migrate.exe. Is this the proposed solution by the EF Team?
Yes. Do this.
Also see issue #6313 where we want to make this experience a little easier on .NET Core.
In order to run .NET Core web application on your server, you need to install .NET Core SDK (currently 1.1) on your servers. Doing so will give you the dotnet command so that you can execute dotnet ef database update on your server environment to update the database to a specified migration.
Related
We have an on-premises Azure DevOps 2019 server, with build pipelines for numerous .Net 4.x solutions that our small team maintains using VS2019.
The team is about to upgrade to VS2022, and at some point I would like to migrate some solutions to .Net 6. Can DevOps 2019 build .Net 6 solutions, and if so what changes are needed to support this (such as presumably installing VS2022 on the server)?
Will those solutions' build pipelines require any changes or should they continue to work as-is? They don't contain anything too clever, with steps such as: NuGet restore, build solution, run unit tests, NuGet pack & push. (The build pipelines are managed via the web GUI, not YAML, if that makes a difference).
Some solutions will remain .Net 4.x, so the server will still need to support (build) these.
You should just need two things:
First you have to install the corresponding SDK for building the apps (see sdk download - Build apps - SDK) on your build-agents.
(Optional) Add or modify your set SDK Task in your pipelines (see use dotnet core task).
One more hint, you don't need to install a whole VS on the server. The Build-Tools are enough (VS2022 Buildtools preview).
I wanted to try and learn using EF Core with my asp.net core apps.
I am very confused what's the difference between a lot of the stuff that's available and hope somebody can explain the differences:
I have been using the GUI Packager Manager for VS a lot, but there seem to be at least THREE more consoles, what's the difference? The descriptions didn't help very much, since the introductory sentence on all of them is pretty much the same... PMC NUGET CLI dotnet CLI
They are all used to install NuGet Packages. Great...
Here the command dotnet tool install --global dotnet-ef is used and labeled .NET CLI, but in my tutorial it is actually executed from the PCM! In addition the tools then are installed in C:\Users\USER_DIR.dotnet\tools which to my understanding has NOTHING to do with a nuget package that is installed inside a VS PROJECT ?!
Result:
But then what are these?
JFF I tried the adding the "dotnet-ef" one to my .NET Core 6 project and I got an error that only Core 3.1 is supported for this.
In any case I'm confused now. I thought tools are global (or path-local) and NuGet Packages are additional .dlls inside your project. Is that true? And if so, how come, that the EF Core tools come in both variants?
I understand I need those to add the EF .dlls to my project
Microsoft.EntityFrameworkCore.SqlServer (if this is the chosen server)
Microsoft.EntityFrameworkCore (is this hard req?)
Microsoft.EntityFrameworkCore.Design (sais microsoft)
But I don't understand what the nuget version of the tools is for. Thanks...
I'm building a .Net app using Entity Framework.
I have TFS vNext Builds setup and I'm doing auto publish to an azure web app.
I'd like to add a build task to automate my entity framework changes.
I'm using code first and have migrations enabled, so I need a task that will run my migrations during the build to make any database schema changes, and seed test data that needs to be added/updated to the database.
Essentially I'd like to get the process used by ReadyRoll
http://www.red-gate.com/products/sql-development/readyroll/
Without having to spend $350 per licence.
You can install EntityFramework nuget package to your project. And then restore the nuget package and call "migrate.exe" in the package folder to run the migration. Refer to this question for details: How can I run Entity Framework's migrate.exe from Visual Studio Online?
I have written an application that I deploy via Clickonce, but I want to deploy it via Installshield, so I am experimenting with it. I found and downloaded dotnetfx45_full_x86_x64.exe, the redistributable for .NET Framework 4.5, and made a Installshield prerequisite from it. I wrote a simple application that has a RDLC report that just says “Hello World”, and it needs .NET Framework 4.5, and used Installshield to deploy it. The Reportviewer needs Microsoft SQLClrTypes_x86.msi and SQLClrTypes_x64.msi, and ReportViewer.msi, so I got those and made Installshield prerequisites from them. For the ReportViewer.prq, I specified SQLClrTypes_x86.prq and SQLClrTypes_x64.prq, as dependencies, and for SQLClrTypes_x86.prq and SQLClrTypes_x64.prq I specified dotnetfx45_full_x86_x64.prq as a dependency.
When I installed my little application on my test computer (running Windows 7), it installed the 4.5 framework, said it needed to reboot, and asked if I wanted to reboot now, and I clicked Yes. I was thinking it would reboot and continue the installation, but when it rebooted, that was the end of the installation. I ran setup again, it asked if I wanted to install the 4.5 Framework (it asked me the first time, too), so I clicked No. After clicking No, it installed the rest of my program, and it ran perfectly.
How can I get the installation to continue after it reboots from installing the .NET Framework 4.5?
Thanks
Here's a blog I wrote about 9 years ago:
Using InstallShield 12 to Install .NET Framework 3.0
It hasn't changed much. You want to use the prereq editor to change the reboot behavior to Note it, fail to resume if the machine is rebooted, and reboot after the installation.
Also please note that InstallShield consumes it's PRQ files from the ISProductFolder (C:\Program Files (x86)\InstallShield.... ) I don't care for this from a CM perspective. I recommend isolating the file and file references to relative paths based on ISProjectFolder and keeping all of these files in your source control tool.
Behavior Tab
We are using enterprise library 4.1 and smart client software factory 2008 to our application.
how we can upgrade enterprise library 5.0 and SCSF 2010 to our application.presently we are using visual studio 2008.
To upgrade what are the thing needs to be taken care.
Early help would be appreciated.
In terms of Enterprise Library, the best case scenario would be to replace the 4.1 assembly references with 5.0 assembly references and change the configuration (to use 5.0 references instead of 4.1 references). However, you could also hit some issues.
You should read the Microsoft Enterprise Library 5.0 Migration Guide for a full description. The Breaking Changes document could also help you determine if you may run in to migration issues.
For the Smart Client Software Factory the approach appears the same: change the references and configuration to use the new dlls. The Web Client Software Factory 2010 Documentation download has a section on Migrating to Visual Studio 2010.
Install the 5.0 package.
remove all the previous refreneces and add the newer ones generated.
You can refer the dlls by copying it to some folders or directly from the location where you have installed (C:\programfiles\Microsoftenterpriselibrary5.0)
I faced the below issues while migrating
Configuration errors in web.config files - some of my references in the web.config files were refering to the older version(2.0.0.0)(i upgraded from 2.0 to 5.0) and the publictokenkey="null"
so i pushed all the dlls to the gac and added the publicktokenkey from the c:\windows\assembly. which solved the issue
And another issue was regarding the microsoft.practices.enterpriselibrary.caching.cryptography- it was displaying soem weird error.- solution-the bin folder was having the old dlls and when tried to
clean the solution the dll reference was still there. SO i deleted all those from the folder and rebuild again.
IT was initially having the logicacmg.enterpriselibraryextensions.logging which caused some issues- i used the microsoft.practices.enterpriselibrary.logging.configuration.rollingflatfiletracelistenerdata which could solve the issue.
Hope some one might get some inputs with this post