How can I enable migrations in a testing project?
PM> Enable-Migrations
Could not load assembly 'CreditoImobiliarioBB.EntityFramework.Test'. (If you are using Code First Migrations inside Visual Studio this can happen if the startUp project for your solution does not reference the project that contains your migrations. You can either change the startUp project for your solution or use the -StartUpProjectName parameter.)
Have you verified that your Startup Project (in Solution Explorer) and your Default Project (in Package Manager Console) are set correctly?
The Startup Project setting should be familiar to you if you've developed any web applications before. e.g. if you have an ASP.NET MVC web project, this should be selected as the startup project (shown in bold) in the Solution Explorer.
As you probably know, this ensures that running the application will load this web project in the browser. In addition to that, you should also know that this is where Migrations will try to locate the web.config file with the proper DB connection string.
The Default Project setting (different from the aforementioned Startup Project) setting is set in a dropdown within the Package Manager Console, where you run commands such as Enable-Migrations, Add-Migration and Update-Database.
I would recommend enabling your migrations in a data layer project. But if you want to use your Test project, make sure you select the name of the Test project in the Default Project dropdown of your Package Manager Console.
Hope this helps!
Related
I would like to create an installer for my self-hosted service written in .NET Core 3.1. I'm using Visual Studio 2019 so I had to install VisualStudioClient.MicrosoftVisualStudio2017InstallerProjects and this allowed me to create Setup Project.
So, everything now works ok, except that I can't run any code during the installation! In standard .NET Framework there was Installer class that enabled me to inject some functions, like "register and start service". But .NET Core has nothing like that!
So how can I run extra C# code after the installation is finished?
It turns out that Installer class is not supported anymore and probably won't be in foreseeable future.
The workaround is to you the service exe itself as as a host for custom code, run be parameters.
Steps:
In the Solution, where your .Net Core service lies add the "Setup Project" project. (it must be the same solution)
Go to File System -> Application Folder and add PublishItemsOutputGroup
Go to custom actions view and add a custom action PublishItemsOutputGroup to Install with your exe name selected. (e.g. it should say (name) PublishItemsOutputGroup from MyApiService (Active))
Set arguments to /my_Install
Go you form Main in the service and add something like:
if (args.Length == 1)
{
File.AppendAllText("test_install_ca.txt", args[0]);
return;
}
Once you run it, you will find test_install_ca.txt in System32 dir with the content /my_Install
I have my ASP.NET Core + Angular WebApp uploaded to GitHub(through VSTS) and now I would like to set up the CI pipeline. After that I would like to deploy my app to Azure.
In the template section - there is an ASP.NET Core template, but also an Azure Web App template.
Considering my case which is better suited for this case?
I found the almost perfect working answer in Levi Fuller's blog.
You can get it working with a minor change: unlike what Levi states, you really need only a single npm task
set up the npm task
by clicking the three dots button -> set the Working folder with package.json to your folder that contains the package.json file.
set up the Azure App Service Deploy
by clicking the three dots button -> set the Package or folder to your folder that contains the .csproj file.
There isn’t the build template that you use directly, the template is convenient to use, you need to modify it per to detail requirement.
Refer to these steps:
Go to build page of team project (e.g. https://XXX.visualstudio.com/[teamproject]/_build)
Click +New button to create a build definition with ASP.NET Core template
Add npm install task before .NET Core Restore task (Command: install; Working folder with package.json:[package.json folder path])
(optional) Delete/disable .NET Core Test task if you don’t need
Add Azure App Service Deploy task at the end (Package or folder: $(build.artifactstagingdirectory)/**/*.zip; Check Publish using Web Deploy option)
Note: you can move step 4 to release and link this build to release (change package or folder to $(System.DefaultWorkingDirectory)/**/*.zip).
Every time I Publish a Web Deployment Package using a Release Build I get this error once I call the Web API;
HTTP 500 Internal Server Error
Could not find file 'C:\SolutionDir\ProjectDir\bin\AssemblyName.xml'
Here is the steps I perform when deploying to the server.
In Visual Studio 2013 right click Project and select Publish...
Check I'm happy with my Publish Profile and click Publish.
Locate the Deploy folder in my Web API Project and copy it to the destination (plus check backups of previous build).
From the server I wish to deploy to I open up Internet Information Server and select the Application I wish to deploy to then right click select Deploy -> Import Application....
Following the Import Application package wizard selecting my deployment package and checking any settings before clicking Finish.
After this process I attempt to test the Web API using Fiddler and receive the error mentioned above. I've tried various methods but nothing has worked so far, the only way I can make it work is by copying the XML files into the bin folder on the server from a Debug build of the project.
What I don't understand is I shouldn't need to do this to make it work, why does Visual Studio / Web Deployment insist the XML exists?
Solutions I've already tried
A: How to prevent the copy of XML documentation files in a release mode build?
A: Preventing referenced assembly PDB and XML files copied to output
A: How to prevent Visual Studio from “publishing” XML documentation files in web projects?
If you create a web API project with certain options it also includes MVC functionality to display web API help pages based on the XML documentation.
I think the Nuget package that will be in the solution is called Microsoft.AspNet.WebApi.HelpPage.
I've never used it, so I'm not up with when it may potentially check for the XML files, but perhaps removing this and the MVC stuff (if you do not use the documentation) will stop it looking for the XML files.
Once a week I get the new version of .net assembly which I need to deploy to our Axapta 2012 installation. I don't want to copy this dll to axapta client folder on each computer. So I am searching the way to deploy it to AOS and hope it will deploy on each client automatically.
I have found many solution (this is one of them), but all of them works only if I have the source code of this assembly. I don't have. And I can not to 'Add VS project to AOT' and deploy it using VS add-ins.
Is there any way to deploy .net assembly (as compiled DLL) from AOS to each client ?
If you cannot do it using the "Add VS projection to AOT" method, you can use the SysFileDeployment class. This is demonstrated in Joris DG his blogpost here.
On msdn the description of the SysFileDeploymentclass is as follows:
The SysFileDeployment class is used for deploying files from the server to the clients.
On msdn it is also explained how you need to do this.Basically all you need to do is extend this class and point to the files you need to deploy (in your case a dll). You will also have to change the build number of you solution to trigger the deployment.
You can also deploy dll's by adding them to the GAC, as demonstrated here:
Axilicious: AX2012 DLL Deployment and how AX binds DLL’s at runtime
To summarize main differences are:
Using the visual studio properties: it is deployed to a folder specific to that user (so a different folder for each user) at the moment it is needed
Using SysFileDeployment: it is copied to the client bin folder, a restart of the client is needed (possibly problems when on citrix/terminal services, like Joris suggests in the link you provided?)
GAC: DLL's are stored in the Global Assembly Cache and different versions are stored but you need to provide a mechanism of deploying them yourself
Personally I would try the SysFileDeployment method as it's the standard method MS provide. If you have trouble, you might receive support.
I want to test ASP.NET application using NUnit, but it seems WebConfigurationManager.ConnectionStrings collection is empty when running from NUnit GUI.
Could you tell me how to initialize this collection (probably in [SetUp] function of [TestFixture])? Should I copy Web.config somethere?
Thank you!
NUnit .config file location depends on how you created the NUnit project file
Where .config files for NUnit tests are located is a little bit more complicated than other posts here suggest. There are settings for this in the NUnit GUI Project/Edit dialogue. The default values all depend upon how you created your NUnit project file.
When you open the NUnit GUI and select File/Open and then select a .dll file a new project gets set up with settings to look for a config file with the same name as the dll in the same directory. So if you loaded \bin\debug\MyTests.dll NUnit looks for \bin\Debug\MyTests.dll.config by default. The only trouble with this is that when you create a release build you need to create a separate NUnit project.
If you have created the NUnit project by selecting File/NewProject then the default setting is to look for a config file with the same name as the NUnit project. So if you created \MyNUnitProject.nunit NUnit looks for \MyNUnitProject.config by default.
The chances are you have used Visual Studio to create an \App.config file and stuck it in the source folder for your test dll. When you buld your test project this gets copied to \bin\Debug\MyTests.dll.config or \bin\Release\MyTests.dll.config depending upon the configuration you have selected. If you have opened the MyTest.dll directly in NUnit this will work fine, however if you have created a new NUnit project you’re in trouble as it will not look for these files by default.
To resolve the issue you need to open up the Project/Edit dialog in the NUnit GUI and check that you have two Configurations Debug & Release to match your .Net project. Once you have done this you can select the Debug Configuration and set the ApplicationBase to bin\Debug\ and set the Configuration File Name to MyTests.dll.config. Do the same for the Release configuration and away you go.
If you have your unit-test assembly named Company.Component.Tests.dll, then just make sure that Company.Component.Tests.dll.config is there with the proper connection string.
Additionally, it might be a good idea to decouple your connection provider class from the configuration, so that you will have flexibility in persistence (i.e.: switching from *.config to something else) and easier testing.
Also check out "How NUnit Finds Config Files"
You can use the app.config for libraries (where I assume your tests are) and put them in there.