We are in the process of switching from Entity Framework 4 to Entity Framework 6. The package manager did its job, and the solution ran it’s tests without a hitch.
However on the build server we get the following error message running the tests:
Initialization method xxx.SetUp threw exception. System.InvalidOperationException:
The Entity Framework provider type
'System.Data.Entity.SqlServer.SqlProviderServices,
EntityFramework.SqlServer' registered in the application config file
for the ADO.NET provider with invariant name 'System.Data.SqlClient'
could not be loaded. Make sure that the assembly-qualified name is
used and that the assembly is available to the running application.
See http://go.microsoft.com/fwlink/?LinkId=260882 for more
information.
If we open the solution locally on the build server, with a Visual Studio installed there, the test run without error again.
We use Cruise Control .Net in combination with SVN as tooling for our continuous integration. Ms Build is used to build the solution and the tests are run with Ms Test.
Has anybody experienced similar problems or has any thoughts on a solution?
This really sucks MS. But fortunately some better programmer than I had the same problem and made this excellent post:
http://robsneuron.blogspot.nl/2013/11/entity-framework-upgrade-to-6.html
Adding this line to our DbContext constructor fixes the problem:
var ensureDLLIsCopied = System.Data.Entity.SqlServer.SqlProviderServices.Instance;
The variable is never used, is not needed when using VS to build, it is only there to make sure Ms Build does its job...
Related
Compilation Error
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: The compiler failed with error code -2146232576.
Clean and Rebuild your solution (under Build menu). If it gives you any compilation errors, correct them and build it again. That worked for me.
Edit 3/12/18
It seems like you have read, or possibly write, locks on one or more files. Close the studio and verify that the source code repository don't have orphaned read/write locks. Also verify that any directories used for compilations don't have read locks. There used to be a weird Temporary ASP.NET-folder that was prone to locking files in the good old days.
Previous response
These are a few things that come to mind in my experience. I am assuming the deployment machine is a Windows Server of sorts.
Check the expected .NET version by checking project properties in Visual Studio (or the Project-files if another editor is used).
Compare with the installed version of .NET of the deployment machine. Framework on the deployment machine should equal to or greater than .
Verify the chosen app pool is running the expected version (or change it) and recycle it.
Make sure all the necessary assembly files (.DLLs) have been included on the deployment machine. A quick look into the BIN or DEBUG folder usually tells the story, but will generally also contains a whole lot more stuff. Sometimes too many assembly files removed during optimisation of the build.
A little bit of information about deployment OS and .NET versions would help.
I have create a sample ASP.NET 5 application (pretty much the example one from New Solution), and pushed it to GIT hosted on Visual Studio Team Services (former Visual Studio Online). I want to set up continuous integration to Azure Web App (former Azure Web Site). I have tried to set it up from Azure portal itself, it did create a new build definition, but it fails to build ASP.NET 5. I have found a guide how to do this, but it never really worked for me, I get errors like this e.g.
Error parsing solution file at C:\a\1\s\Frontend\src\Frontend\Frontend.xproj: Exception has been thrown by the target of an invocation.
Predefined type 'System.Void' is not defined or imported
Another problem is that it seems it really takes a lot of time to install dnvm, get packages, etc. So all in all it's a pain to make it work.
So are there real alternatives for that or more importantly is Microsoft is planning to implement something like a Build ASP.NET 5, Deploy ASP.NET to Azure and such to make it easy as I suppose it's easy with the current ASP.NET 4 apps. I really hope that it will be an option soon since it's quite impossible to work with current build system.
For "System.Void" issue, please check the runtime version in "global.json" file and make sure it is consistent with the dependencies in "project.json" file.
For dnvm install issue, since AspNet5 runtime environment isn't installed on VSTS Hosted Build Agent for now and the different users may use different runtime versions, it requires the user to add a "PreBuild" PowerShell step to read the runtime version in "global.json" file and then install it. If you can make sure that you will always only use one version (For example: 1.0.0-rc1-update1), you can deploy your own build agent and install "1.0.0-rc1-update1" on it, then you can skip the dnvm installation during the build process.
Take a look on http://riffer.eu/wordpress/?p=112. There I have a solution vor asp.net core RC_1.
Amazingly you need only two powershell scripts - there is no compiling / visual studio necessary.
I'm trying to get a project to work with a continuous integration build. Currently, it consists of a library dll, .net 4.5 app, and WP8 app. I use team foundation service with GIT as my source control.
I was able to set up a build configuration but it fails with the following message:
Exception Message: MSBuild error 1 has ended this build. You can find more specific information about the cause of this error in above messages. (type BuildProcessTerminateException)
Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context)
at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
This is the ONLY exception in the entire solution, although there are 10 warnings. Additionally, I've run the build with the verbosity to diagnostic and here is the output of that.
Again I don't see any issues with that build, just the cryptic "Done building project.... --FAILED" message. Locally, the project can be built and rebuilt without any issues. Anyone have any idea what might be causing this issue?
Edit:
Through trial and error I've narrowed the issue down to having a windows phone 8 application in my solution. If I exclude that project, the solution builds fine. If it's included, I get the problem. Should I perhaps be using a separate build definition for each project and not for the solution itself? Windows phone 8 projects by themselves build fine...
The error you're getting is occurring within the build template that your build definition is using. Build templates are Windows Workflow files that guide TFS Build through the process of executing a given build. The reason why your project is building locally is that Visual Studio isn't using this build template, as build templates only run on the server under TFS Build.
I dare say someone has customised the build template that your build is using, and that customisation is failing. Based on the error, it seems to be happening during the execution of a CodeActivity, which is now obsolete (though being obsolete isn't actually the issue). The custom code in that CodeActivity is probably failing though.
Assuming your build process doesn't need any specific customisations provided by the failing build template, I'd just select a different one or create a new one. You can do this from the Process tab when editing the build definition.
Hope this helps!
I have a build-server running CC.Net. So far I never had any problems compiling projects on the build server (which has no VS installed, just use the .Net Framework).
But now I have a new projects and I get this message:
C:\Program Files\MSBuild\Microsoft\Windows Workflow Foundation\v3.5\Workflow.Targets(127,5): error : Compilation failed. Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
Has anyone any hint's on what's causing this problem?
What might be of some interest is the fact, that this is a SharePoint project wich includes a SharePoint workflow. But this shouldn't stop the project from being able to be compiled.
The problem with LoaderExceptions described here sounds like what you are seeing. Maybe targeting 3.0 instead of 3.5 does fix your issue too.
I have a VB.Net 1.1 application works just fine after compiling in Visual Studio. However, I want to use ILMerge to combine all the referenced assemblies into a single executable just to make it easier to move around. After I send it through ILMerge and try to run it I get the error
"Strong name validation failed for assembly.exe" .....
But none of my stuff is strong named! I saw this post here: Strong Name Validation Failed and tried running it through 'sn.exe -Vr merged.exe' but that gives me this error:
"merged.exe does not represent a strongly named assembly"
Has anyone else had this problem before? How do I fix it?
UPDATE:
I'm starting to feel like Strong name validation isn't the real problem here. I'm building against .NET v1.1 and running on a machine where that is the only .NET version installed (happens to be Windows 2003). The merged executable appears to die with that error on every Windows 2003 machine I try, but if I try to run it on a more modern OS (Vista) it at least starts, but that's not really a good test since the environment isn't fit for a real test.
I have verified that my app.config has the correct settings (specifying required and supported runtime version of v1.1.4322)
I use the /targetplatform:v1.1 option when running my assemblies through ILMerge.
ILMerge is definitely causing the problem (i.e. it works fine before I merge), I just don't know how to fix it.
I had to find and download a very old version of ILMerge (v1.1) in order for my merged binary to work; there must be a bug in the way the current ILMerge application builds .NET 1.1 assemblies. Thankfully we had one internally because I would probably have never found it online.