Develop Reference

Entity Framework: Error "Cannot bind argument to parameter 'Path' " on "database-update"

I'm getting this error when I try to update my database
Update-Database : Cannot bind argument to parameter 'Path' because it
is null. At line:1 char:2
Update-Database
CategoryInfo : InvalidData: (:) [Update-Database], ParameterBindingValidationException
FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Update-Database
can you point me in the right direction to solve the problem?
thank you

This bug has been reported on GitHub (see issues 1290, 1306, 1348). It was fixed (by the reporter of issue 1290) and is available in nightly builds. It was first scheduled for the 6.4.0 release (scheduled for late November/early December per this comment) but has since been moved to a 6.3.1 release. Neither milestone has a due date as of writing this.
The bug only affects EF Migrations and it only applies to using a Web Application project as the startup project (even if your entities and context are in different projects). If affects multiple commands (Enable-Migrations, Add-Migration, Update-Database, and Get-Migrations) because they call into the code that contains the bug.
If you need to use Migrations, either downgrade to version 6.2.0 or use one of the workarounds that have been identified.
If you downgrade, make sure do it to all projects that use it within the solution. If the 6.3.0 package is referenced by any project, the 6.3.0 PowerShell module will take precedence. You can use the "Manage NuGet Packages for Solution..." command from the solution node to help identify where 6.3.0 might still be installed in any projects. Once that's done, you'll need to close and reopen the project in order to load 6.2.0's PowerShell module.
Workarounds
If you want/need to use version 6.3 and you're encountering this error, there are several workarounds you can try. Here's what I've been able to put together:
Use a Console Application as the startup project.
Because the bug only affects Web application projects, the conditional branch that has causes the error is never executed. If you already have a console application with the right connection string, you can use that. If you don't, you can add a dummy project for this purpose.
Note: If your connection string includes |DataDirectory|, this won't work because it avoids specifying the --data-dir argument in order to avoid the bug.
Use a nightly build.
Although this works, it's probably a non-starter for a lot of projects because pre-release builds are generally disallowed in production. If your production release is still several months away, though, it might be an option if you're willing to proceed with the hope that a working release becomes available in time.
Add a dummy project that references a nightly build.
Similar to using a nightly build, you're referencing it in an unused project in order to load the fixed PowerShell module. You would still reference the released version in the projects used by the application.
Modify the local package in the shared cache location.
Caution: This is not a tenable solution for teams (or CI/CD environments) but it might be okay for an individual who wants to use a quick hack while waiting for the next release and doesn't mind reapplying it if the shared cache gets cleared.
If you're using PackageReference tags in your project files, assemblies are referenced in a shared cache location, usually under %USERPROFILE%\.nuget\packages. You can modify the file there as shown in issue 1290 and it will be used by all projects that use the package via PackageReference tags. If you're using packages.config you have to modify it in the packages folder and that's more likely to be lost.
I have tested all of these workarounds with successful outcomes.

loading multiple.net assemblies with same AssemblyVersion from a plugin

I'm in dll hell.
I'm building a plugin for a huge, ancient and very powerful software suite called ANSYS. They have a plugin framework. I had hoped that they would magically handle everything for me via AssemblyContexts or AppDomains or some other clever dotnet device that I don't understand. They do not.
The result is that I've created an application that depends on GRPC.core 1.16.0 via nuget. I wrote a little application that drives my plugin with a winform host. It loads and works perfectly, finding my library in ~/myproject/bin/debug/grpc.core.1.1.16.dll that exists right beside the class-library that is my plugin, no problem.
When I run my plugin in the ANSYS process space, which happens to also depend on grpc 1.0.0.0, the linker finds C:\Program FIles\ANSYS\...\WIN64\grpc.core.dll. No Good.
One odd thing about the Nuget GRPC package is that it adds a reference with a "reference version" of 1.0.0.0, where most other nuget packages have their reference version match the nuget package version. If i manually change the reference version the compiler wont find the library.
<Reference Include="Grpc.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d754f35622e28bad">
<HintPath>..\packages\Grpc.Core.1.16.1\lib\net45\Grpc.Core.dll</HintPath>
</Reference>
edit: the key is in the above line. The Nuget published Grpc.core artifact is at AssemblyInformationVersion=1.16.1.0, AssemblyFileVersion=1.16.1.0, AssemblyVersion=1.0.0.0. I logged this as a request against GRPC. More Below.
Thus I need to tell the runtime linking facilities not to use grpc.core...dll found in ANSYS's own binary directoryWhats more, there is exactly one dll (and its dependents) that I wish to load from my parent processes context: and that's ANSYS API dlls themselves, which are probably already in the GAC. In my project I've included this as a non-nuget reference with "build action: do not copy" selected.
So my questions:
is there something simple and easy I can do at runtime to tell the runtime-linker "when somebody loads a type from an assembly you think should be grpc.core, do not load 1.0.0.0, find 1.16.0.0 exactly"?
the runtime was already matching the needed library by "strong
name". The problem is that the 1.16.0 is a misnomer. That version
string was informational, but the assembly itself was version
1.0.0.0. Fusion was loading the library I wanted by exact match already.
is there something smarter I can do with appdomains or contexts or another C# device to explictly enter some kind of nested scope? Could I go so far as to log this as a bug in ANSYS's API?
I've tried digging into this myself, but I'm not a dotnet expert and finding out whether I'm looking at a nuget package configuration option --which isn't relevant to me, or an old-fashioned dotnet runtime option, has been very tricky.
update 1:
I've tried using AppDomain.CreateDomain, and it does indeed solve my problem, but it also requires me to provide a marshalling strategy for the already-loaded API objects. In other words, if you're programming against a plugin framework that has an api similar to:
public void DoMyPluginsFunctionality(ApiProvidedInputContext context){
var myPlugin = AppDomain.Create(
strongName: "MyCompany.MyPlugin.; Version=1.2.3.4 ...",
baseDirectory: "C:\\Program Files\\MyPlugin\\bin"
)
//success! MyCompany.MyPlugin loads the version of GRPC I want!
myPlugin.unWrapAsDynamicProxy().doFunctionality(context)
//error: No marshalling strategy and/or not serializable and/or swizzling errors
}
Then the runtime will require you to marshall (serialize) the context variable, because .net will not let you share memory across AppDomain boundaries.
So my new question:
- given I cant use AppDomains myself
- given that Grpc.core is always published as AssemblyVersion=1.0.0.0
What are my options?
Stop using newer features of GRPC.core and live in fear of my parent processes dependencies
use a strategy similar to shading. Is there something like shading in the .net world?
Edit the published binary's version metadata. Can I dynamically edit a published binaries version?
rebuild GRPC myself with the version string updated --effectively a private fork of GRPC.
update 2:
The GRPC build system seems like its quite large and well maintained, so I'm hoping I can simply build it and change a vcproj file to include an updated version string.
Unfortunately it also seems quite complex, and I haven't quite got the targeting/cross-compiling (x64 targeting x86) worked out.

Install-Package : Failed to add reference to 'System.Runtime'

I'm trying to install the Autofac nuget package in my project using the command
Install-Package -Prerelease Autofac
but it fails with the error
Install-Package : Failed to add reference to 'System.Runtime'. Please make sure that it is in the Global Assembly Cache.
I've tried re-installing .NET Framework 4.5.2 (which is the version my project targets) but got the message ".NET Framework 4.5.2 is already installed". However, searching C:\Windows\assembly\ for System.Runtime.dll doesn't find any exact matches (although there are a few instances of System.Runtime.ni.dll, which (seem to indicate) that they are really the same assembly...).
What can I do about this?
Update: apparently I was confused about the location of the GAC. Amy enlightened me, and searching in C:\Windows\Microsoft.NET\assembly instead I do find System.Runtime.dll. Why doesn't Visual Studio?

I had the same problem.
Found the solution here: https://github.com/aspnet/WebHooks/issues/18
To fix it, I added <Reference Include="System.Runtime"/> to the .csproj
file for the project, rebuilt it and it worked.

Please make sure that it is in the Global Assembly Cache.
That is an excessively unhelpful error message. It not only doesn't describe the real problem, it also leads you drastically astray to find a workaround. An assembly reference for a .NET Framework assembly must never come from the GAC. The kind of failure modes when it does can be exceedingly nasty to diagnose. Reference assemblies must come from the C:\Program Files (x86)\Reference Assemblies directory.
Looking at the .nuspec file for the Autofac nuget package you are trying to install, it supports two distinct targets. One is for DNXCore version 4.0.10-beta-22816. Hopefully you are not using it, that project is changing rapidly.
The other is .NET Portable, profile 259. Which allows your project to target .NET 4.5.x, Store, Phone80 and Phone81. What the blunt error message is telling you is that it has trouble finding that profile. Use Windows Explorer to have a look-see, the profile is stored in the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable\v4.5\Profile\Profile259 directory. It has the required System.Runtime.dll reference assembly.
Well, surely it awol, I can't guess at the underlying reason.
They did make subtle mistakes in the .nuspec file. Do consider a more stable release of Autofac, you probably don't want to be a beta tester. And don't target 4.5.2, there is no point to that. It doesn't add anything interesting and forcing your user to update his .NET install is not very reasonable.

Build Banshee: Missing dependencies

I'm trying to build banshee from source. I ran autogen.sh and here's (some of) the output:
configure: error: Package requirements (gstreamer-0.10 >= 0.10.26
gstreamer-base-0.10 >= 0.10.26
gstreamer-plugins-base-0.10 >= 0.10.26
gstreamer-controller-0.10 >= 0.10.26
gstreamer-dataprotocol-0.10 >= 0.10.26
gstreamer-fft-0.10 >= 0.10.26) were not met:
No package 'gstreamer-0.10' found
No package 'gstreamer-base-0.10' found
No package 'gstreamer-plugins-base-0.10' found
No package 'gstreamer-controller-0.10' found
No package 'gstreamer-dataprotocol-0.10' found
No package 'gstreamer-fft-0.10' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables GST_CFLAGS
and GST_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
Error: Could not run ./configure, which is required to configure banshee
I've already ran sudo apt-get build-dep banshee, so I have no idea how to solve this problem.

There are different types of dependencies, build time dependencies and run time dependencies. You will often need more dependencies to build a program than what you need to run it. For example, running a program may require a shared library. Building the program may however also require a header file. When you installed banshee you would typically install all the run time dependencies along with it, but not the build time dependencies. Since you're using apt-get you should investigate which packages you need to install in order to get the required build dependencies.
The error message that you received is from a program called pkg-config. It's typically used for tracking build dependencies. Some libraries may for example require different compiler flags on different systems, so pkg-config has a directory of libraries which is knows how to use. Here Banshee's build system calls pkg-config in order to find the correct flags for using the gstreamer libraries, but since the development files for gstreamer are not installed pkg-config won't know how to use them. Once the development files for a package that uses pkg-config are installed the flags can be requested by running pkg-config, for example pkg-config --cflags --libs gstreamer-0.10 would return the preprocessor, compiler and link flags for the gstreamer-0.10 library.
The files that pkg-config uses is typically named name-of-library.pc. Use your package manager to search for files such as gstreamer-0.10.pc, gstreamer-base-0.10.pc and so on for all packages that pkg-config could not find. Systems which uses apt-get usually has a tool (although not necessarily installed by default) called apt-file which can be used to query the package manager for the name of packages that supply a specific file, for example apt-file search gstreamer-0.10.pc. Many distributions such as Debian or Ubuntu also has web interfaces that supports searching for packages based on file names.
You can sometimes install the required build dependencies by running apt-get build-dep name-of-package. It will install the packages needed to build the program. However that will install the requirements for building the version of the package that your package manager distributes. The version you're building might have different dependencies, but if the requirements are the same then that should usually give you what you need.

Obviously, Marcus' answer is awesome, but if you want to go to the point, the answer is: sudo apt-get install libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev
I will update Banshee website right now: done.

Problems loading git2.dll?

Im trying to use the libgit2sharp library. My only code is
Repository repository = new Repository(#"C:\Path\To\Repo");
and when i run it i get an error saying Unable to load DLL 'git2': The specified module could not be found. So, I manually went and grabbed the git2.dll from libgit2sharp and moved it into the directory. When running the same program after that I get another error: An attempt was made to load a program with an incorrect format.
While researching this I found this post and the solution that seemed to work for the poster there didnt work for me. That post was also made a year ago and a supposed fix was made for it, Im using the latest branch of libgit2sharp (ive tried older repositories no change)
Any ideas?

The recommended option would be to install the latest LibGit2Sharp NuGet package which will take care of installing everything in the correct location.
However, if you prefer to handle this by hand, the GitHub repository includes both x86 and amd64 version of the git2.dll. Performing a checkout of the master or vNext branch should retrieve them.
Beware that every version of LibGit2Sharp works against a specific version of the libgit2 binary. Each LibGit2Sharp branch contains a libgit2 submodule which points at the libgit2 commit being wrapped.
In order for it to perfectly work, the LibGit2Sharp assembly expects the git2.dll binary to be located into a specific tree structure.
LibGit2Sharp.dll
|__NativeBinaries
|__x86
| |_git2.dll
|
|__amd64
|_git2.dll