Upgrading to EF6 in entire solution - entity-framework

I would like to upgrade from EF4 to 6 and I'm looking for easiest way to update references.
Right now, references are not from NuGet but from custom location. My sln is quite big and its contain a lot of projects which have EF model.
Question is,
do I need run
Install-Package EntityFramework
for each project inside sln manually? It would be nice to have possibility to run this command for all project with EF at once.
Thank you.

From the command line you can run something like the following:
Update-package -Id Entityframework -ProjectName xxx
However on solution level I always find it quite easier to do it using UI:
Manage NuGet Packages
Search for EntityFramework
Install it on one of your projects
Go to Installed Packages + Manage
Tick all the projects you want to have the EF reference

Related

Nuget command to replace existing references with nuget references?

In VS2017 I created a new Winforms project using the XAF Solutions Wizard ( Entity Framework Code - First)
The wizard adds references according to options I select.
Now I want to change all the packages to use my Nuget Feed for the Dev Express References.
XAF does have Nuget packages
Is there a Nuget command that I can use to do this automatically?
Cross posted to Dev Express
There is no way to do this with Nugets unless you script your way out as we are doing in XAF community project expandFramework. For some cases it won't work, however for a similar case here is what we do.
Parse all your projects for References start with DevExpress and construct a list of assemblies
For all assemblies in the list add them to packages.config
For all assemblies use the DevExpress.PackageContent project to link to the containing the packages.
Get-DxNugets 18.2.6
Install the found packages from step 3
`Nuget Install packageName -OutputFolder $commonOutputFolder
Update the DevExpress references HintPath to the packages installation folder.
Update-HintPath -OutputPath "$packageInstallationfolder" -SourcesPath $rootPath -filter "DevExpress*"
all powershell functions come from the XpandPosh project. There are many helpful methods there unfortunately no docs. But you can get support

What is the most standard way to get the latest version of an assembly solution-wide using NuGet?

My company is moving to using NuGet for our internal dependencies for desktop applications. This works fine for versioned imports, but in some cases (like during pre-Beta on a product) we'd like to grab the latest version of the dependency on our build servers and have the csproj files find it without issue.
We'd like to use automatic package restore, but that seems to be constrained by a specific version (as noted in this question). Using nuget restore followed by nuget update is also a possibility, but it doesn't seem to work solution-wide the way that restore does (and we have a couple dozen projects that have to share the same version of the same dependency).
Our best solution so far has been to add a hint path to the dependency binary in a non-versioned manner, i.e.,
<Reference Include="Dependency">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\packages\Dependency\lib\net40\Dependency.dll</HintPath>
</Reference>
And use the pre-build event to run
nuget.exe install Dependency -NoCache -ExcludeVersion
Is there a better way to do this? It would be nice to do it the most standard way possible so that we can get tooling support and new developers to the project can more easily know how to add their own dependencies via NuGet.
As of Nuget.exe v2.8.3, there isn't any way to do a solution-wide restore and update (at least when not all the projects in a given folder hierarchy are part of a solution). We ended up using the workflow described in How do I update a single nuget package in a project from the command line?.

How do I correctly install nuget packages outside of VS and keep track of them?

I'm trying to use nuget.exe outside of Visual Studio as part of our build infrastructure. The idea is that the various build tools are fetched by a bootstrapper script that initializes a working copy. The bootstrapper does this by using a file that specifies the required tools and their version.
Broken approach 1 - use manually edited packages.config
At first, it seemed like a good idea to keep a manually edited packages.config file and use nuget restore to install them during bootstrapping. However, this does not work for tools that have dependencies, unless I list every single dependency in the packages.config as well, a much to arduous approach to be feasible, because I found no easy way to recursively find all dependencies of a package.
See also using nuget.exe commandline to install dependency .
Broken approach 2 - use nuget install to update packages.config
The second idea was then to use nuget install to install the packages, and let that command update the packages.config, very similar to the Install-Package cmdlet in the package manager console. But, surprisingly, nuget install does not support this! It either takes a packages.config or a package ID as parameter, but I found no way to update the packages.config with the new package and its dependencies.
This problem can also be found in another (two year old) SO question, see nuget.exe install not updating packages.config (or .csproj)?.
Is there a working (and non-hacky) approach at all?
This must be a problem that many people face when using nuget outside of VS, so what is the best approach in that case?
Of course, I could just parse the packages.config and emit a nuget install for each package, but I really don't want to re-invent the dependency management part of nuget, this is what I'm using nuget for in the first place. So I'm left with the feeling that either an -WithDependencies switch on nuget restore or an -UpdatePackagesConfig switch on nuget install is missing...
Note that there are other SO questions regarding the broken approaches described above. What I'd like to know it what the best approach is to solve the root problem, i.e. manage packages with dependencies outside of VS.
nuget install does not currently make changes to the project file.
nuget install can be used to either restore the NuGet packages listed in a packages.config file or download and extract them.
If you do not need the project being modified then your solution of reading the packages in the packages.config file and calling nuget install seems like a reasonable approach.
If you need the project to be modified then you could look at one of the following:
Ripple - a command line tool that adds extra features to NuGet. It has a ripple install command line which is similar to nuget install but it also updates the project file. It has a lot of other features for supporting build servers so this might be a good fit.
NuGet packages outside of Visual Studio with SharpDevelop - this was an experiment I put together to see whether full NuGet support could be achieved, including PowerShell scripts, from the command line without using Visual Studio. It uses PowerShell and quite a bit of SharpDevelop.
Customise NuGet.exe to do what you need. nuget update, for example, does modify the project file, at least for file references, but will not run PowerShell scripts. So you could take the NuGet.exe source code and extend it.
Of the above only 3) would give you exactly what you need. The other two would require a bit of work to read the packages from the packages.config file or some other list and then install them.
See my answer to Why does the nuget command line tool not follow dependencies?
nuget install My.Package.Id will follow dependencies. However, if you want to install multiple packages, you will need to create a batch file with a separate nuget install command for each package. These are top-level packages. You don't need to "install" the dependencies, as they will get downloaded automatically.
If you ultimately want a packages.config file, I imagine you can generate one by enumerating all the packages that were downloaded. However, you would have to take care not to include multiple versions of the same package.
I believe that how nuget 3 works with project.json files may do what you are looking for. Essentially my understanding is that the unit of dependency becomes the package and not necessarily individual assemblies. From what I recall, the idea is the have only one place to manage these types of package references which the project (IDE/Editor), package manager, and other command line tools can use.
What I don't understand and feel somewhat frustrated about is that it appears that the project.json concept is being canceled. I don't know if plans are to reintroduce it at anytime in the future. In the mean time I keep on hearing updated info on tooling that takes advantage of project.json such as nuget so where you can actually rely on this is something that is unclear to me at this point.

Best way to update an existing third party reference to that from NuGet

I have been trying to use NuGet in a complex solution (with around 100 project files) and been struggling with updating the existing references (from a /ext/.. directory ) to that of official NuGet directory. As far as I understand we need to manually select the project files (from the PackagaManager GUI/Manage Assemblies) and update the references. This is cumbersome to know which project uses what out of 100 odd projects. Is there any way (built-in to nuget or any other workaround) to update assemblies to nuget directory without having to manually select projects?
This is not supported as yet and I've registered an issue under codeplex's nuget project.

Should i go for the EF 4.2 update through nuget or a standalone installer?

I would also like to know how the GAC works when i am using a standalone installer ?
Will it override my existing assembly int the project ?
if i have the express edition vs 2010 which does not have nuget ,how do i best make use of these packages without breaking my existing stuff?
You're asking several different questions here.
Generally, the GAC always overrides the bin folder for a given version of an assembly. However, if the bin assembly has a different version, and your config file points to that version, it will use that instead of the GAC.
With VS Express that doesn't have the NuGet VSIX, using NuGet is definitely a bit harder. You need to get the NuGet command line tool, and run the install command to download packages, which you can then manually reference in your projects.