I have been trying to find out the differences between EntityFramework.Core and EntityFramework.MicrosoftSqlServer to figure out which one of the packages I need. I did not notice until today that in my Visual Studio solution, which has both a WebUI project and DataAccess project, that the WebUI only includes EntityFramework.MicrosoftSqlServer while the DataAccess project only includes EntityFramework.Core.
What is the real difference between the two and when should I include one vs. the other vs. both? I am using ASP.Net 5 Core for the entire solution.
EntityFramework.MicrosoftSqlServer depends on EntityFramework.Relational which in turn depends on EntityFramework.Core. Restoring the project is about creating the dependency graph and installing all required packages (regardless of whether they were specified in your project.json or not) into the project.
In your case you specified just EntityFramework.MicrosoftSqlServer but during restore the other dependencies (including EntityFramework.Core) will be pulled so it is not necessary to specify EntityFramework.Core explicitly.
If you are on dnx you can see the dependency graph using dnu list (you can use the --details flag to see even more details) or, if you are brave, you can take a look at the project.lock.json file.
Both are required but if you add EntityFramework.MicrosoftSqlServer then EntityFramework.Core will be added for you as it is a required by EntityFramework.MicrosoftSqlServer.
EntityFramework.Core contains all of the core code of EntityFramework such as DbContext, DbSet and any IQueryable extensions aswell as alot of other internal code.
EntityFramework.MicrosoftSqlServer contains the database specific sql syntax and connection code for sql server. There are other database providers available.
Available database providers:
EntityFramework.InMemory (this is good for writing tests that dont need a database)
EntityFramework.Sqlite
EntityFramework.MicrosoftSqlServer
Related
I have two independent .net projects. One is like a project which is baiscalliy to process invoice and another project is something which I am calling as common as I am keeping all sharable/reusable code under that.
Now any project can consume this common-project by adding it via add Existing project option so that source code will not move to consumer project which is Invoice management in my case.
Now if I add common project as reference and run my CI pipeline its failed as its not able to find the path of common project which is obvious as it may be different from my local machine to build server.
Now the solution that I am aware of are below :
Make common as Nuget package and use it under invoice management.
Build common project dll at some centralized file server and give that path in Invoice management
for reference instead of absolute path.
Both solutions are not simple to implement so I am looking for any better quick solution for the situation where project setup is like this and CI build has to execute.
The best would be actually reference via NuGet package. However, there is a third option which I do not recommend. You can use multiple repository pipeline. You will checkout there two repositories. In thi case you have to mimic folder structure wich you will get on AzureDevops. Otherwise build will fail as it will not find the references.
The paket.dependencies sample file produced when running dotnet new fake currently looks like:
// [ FAKE GROUP ]
group Build
source https://api.nuget.org/v3/index.json
nuget Fake.DotNet.Cli
nuget Fake.IO.FileSystem
nuget Fake.Core.Target
I understand how dependency groups can be used to solve version conflicts, however it seems unnecessary to introduce them until an actual version conflict situation arises.
What is the semantic of the Build group here and why not just have the three dependencies under the Main default group? The same reflection applies to the Test group in the Paket documentation example.
Can one elaborate on reasons for segregating dependencies in groups in the case of no version conflicts? Maybe explaining a bit more the rationale behind the Build and Test groups?
As I have basically introduced that split for FAKE 5:
The reasoning is that one set of the dependencies is used at BUILD-time (ie when running the build script) and one is for your project RUN-time. It is completely valid to have a different set of dependencies for those two.
Consider the following scenario: You use the FSharp.Formatting (FSF, a markdown parser) project in your build process to generate API documentation and in your project to generate websites. Now you want to update the API documentation by updating FSF but you cannot upgrade FSF in your project for compatibility reasons. With the separation between BUILD and RUN-time this is not a problem and you can see them as "different" dependencies in different versions.
I'd like to see that approach similar to how node separates dependencies and dev-dependencies
Regarding the split between RUN and TEST: Personally I'm not a huge fan. I can see how people want to separate their dependencies but paket currently doesn't "really" support that scenario and you can indeed run into issues with that approach. My current suggestion would be to not split between RUN and TEST and manage them in a single group.
To properly split between RUN & TEST paket would need a new feature to reference another group:
group Run
source https://api.nuget.org/v3/index.json
nuget MyDep1
group Test
reference_group Run
source https://api.nuget.org/v3/index.json
nuget MyRunner1
Similar to the external lock-file feature: https://github.com/fsprojects/Paket/pull/3062#issuecomment-367658114
I StructureMap as a way to do DI in my project. I want to create sitemap in my project.
I install MvcSiteMapProvider MVC4 StructureMap Dependency Injection Configuration from NuGet.
it requires manual config but I don't know how to config this.
thanks for your helps
If you installed MvcSiteMapProvider.MVC4.DI.StructureMap into your project, it does not require manual configuration. This package is for use when you don't already have DI in your project - it contains a composition root which is meant to be used as the single place to register all of your DI configuration for your entire project.
However, if you installed MvcSiteMapProvider.MVC4.DI.StructureMap.Modules into your project, it requires manual configuration. This package is meant to be used in projects that have a pre-existing DI setup. You just need to follow the instructions in the readme file in order to add it to your existing configuration. The exact procedure and could vary greatly from one project to another, but the readme contains all of the required and optional lines of code that will need to be added. The key is that you need to ensure that only 1 DI container is instantiated for the entire project and that all of the modules are registered with it.
Do note that MvcSiteMapProvider.MVC4.DI.StructureMap depends on MvcSiteMapProvider.MVC4.DI.StructureMap.Modules, so you can easily downgrade with a single package manager command.
PM> Uninstall-Package MvcSiteMapProvider.MVC4.DI.StructureMap
Make sure you don't use the -RemoveDependencies option.
I upgraded my MVC 4 app to MVC 5 a couple of days ago following these instructions and now I'm getting the following error. I updated DotNetOpenAuth to the latest bits using Nuget (v4.3.3.13295) but it still throws this error.
How do I fix this?
Inheritance security rules violated by type:
'DotNetOpenAuth.Messaging.OutgoingWebResponseActionResult'. Derived
types must either match the security accessibility of the base type or
be less accessible.
Solved this finally. Turned out that I needed to make some changes to the source code of DotNetOpenAuth and re-compile it. This wasn’t easy at all since the source code won’t compile after downloading from github. I had to spend ~3 days trying various things and learning the build system meshed into DotNetOpenAuth’s project files until I finally got it to compile. Seems the author of this project has abandoned it. See more about this issue here.
Download the 4.3 code base using this command line: git clone -b v4.3 https://github.com/DotNetOpenAuth/DotNetOpenAuth.git
Edit the /src/version.txt and change it to 4.4.0. This makes this version higher than the official Nuget release so that installing Nuget packages don’t attempt to install old versions of DotNetOpenAuth assemblies from its repository.
Remove all instances of the following string from all AssemblyInfo.cs files under the /src/ directory.
[assembly: AllowPartiallyTrustedCallers]
I had to mess around with the Microsoft.Contracts reference in two projects and point it to /tools/Contracts/PublicAssemblies/v3.5/Microsoft.Contracts.dll and then use a using alias to get classes from this assembly to resolve properly. A few Requires.NotNull() lines refused to compile so I just commented them out… c'est la vie..
Run the following command to skip verification of these assemblies: sn.exe -Vr *,2780ccd10d57b246
Once the assemblies were built I referenced those, re-added Microsoft.AspNet.WebPages.OAuth 3.0 from Nuget, rebuilt my solution, and finally my app is up and running on MVC 5.
I have four assemblies (plus the .NET 3.5 system.core) that I am installing as unsafe CLR assemblies in a SQL Server 2005 database. Installing the assemblies in the correct order (based on their dependencies) works fine, and I am able to use the CLR functions I need. If possible, I would like to use ILMerge on the four assemblies so that I can install just one DLL. Only one assembly is directly referenced from the SQL side anyway; the others are dependencies. It happens that one of those four assemblies is an XmlSerializer assembly generated with sgen, which is required because the SQL Server CLR will not allow the serializer to be created at runtime.
In the following discussion, the assemblies are called:
ClrIntegration.dll (this is a CLR library in Visual Studio 2008 and is the only library actually referenced from SQL)
CalcLibrary.dll (this is just a .NET 3.5 library that ClrIntegration.dll uses)
CalcLibrary.Schema.dll (this is a .NET 3.5 library whose code is generated entirely by running xsd.exe on two .xsd files -- CalcLibrary.dll uses this library)
CalcLibrary.Schema.XmlSerializers.dll (this is generated by running sgen on CalcLibrary.Schema and is used automatically by an XmlSerializer in CalcLibrary.dll)
To my knowledge, it is not possible to reference the version of CalcLibrary.dll that is in my VS2008 solution directly from the ClrIntegration project. Instead, I have to install CalcLibrary.dll on a running SQL Server 2005 instance and add it as a database reference to the ClrIntegration project. This is a nuisance, but I've made it work so far.
The basic command line I am using as a post-build event in the ClrIntegration project is:
"c:\Program Files (x86)\Microsoft\ILMerge\ILMerge.exe" /targetplatform:v2 /out:ClrMergedAssembly.dll \
"$(TargetDir)ClrIntegration.dll" \
"$(SolutionDir)Source\CalcLibrary\$(OutDir)CalcLibrary.dll" \
"$(SolutionDir)Source\CalcLibrary.Schema\$(OutDir)CalcLibrary.Schema.dll" \
"$(SolutionDir)Source\CalcLibrary.Schema\$(OutDir)CalcLibrary.Schema.XmlSerializers.dll"
I'm running into a few problems here.
If I just run ILMerge as shown above, it works, and I get ClrMergedAssembly.dll. I can install ClrMergedAssembly.dll on SQL Server 2005, but when I try to use it, anything that uses XmlSerializer gives me an error like:
A .NET Framework error occurred during execution of user-defined routine or aggregate "Whatever":
System.InvalidOperationException: Cannot load dynamically generated serialization assembly. In some hosting environments assembly load functionality is restricted, consider using pre-generated serializer.
This is the same error I get when not generating the XmlSerializer at all. I found this excellent blog entry stating that sgen needs to be run again after ILMerge, but doing so creates two problems. First, I really need sgen to be run only on CalcLibrary.Schema.dll. Running it on the whole assembly will fail badly; in fact, that is why CalcLibrary.Schema is separate from CalcLibrary in the first place. Second, having the serializer be separate somewhat defeats the purpose of using ILMerge at all: I want just one DLL to deploy. Are there any solutions here?
The ILMerge.doc file that comes with the ILMerge installation seems to suggest that adding /union and/or /closed might solve some problems. But, using either /union alone or /union along with /closed causes ILMerge to fail with the following error:
An exception occurred during merging:
Unresolved assembly reference not allowed: CalcLibrary.
A stack trace follows the error. My suspicion is that, because ClrIntegration must reference the database version of CalcLibrary rather than the VS2008 solution's version, ILMerge cannot find the type and, therefore, cannot complete the union even though CalcLibrary.dll is the same library. Is my suspicion correct? Is there any way around this issue?
You can't. The framework code always looks for the sgen generated classes in a different assembly - the one named with .XmlSerializers suffix - and it is hardcoded in the framework. Check with your decompilation tool of choice.