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.
I got a problem upgrading Xamarin.Forms nuget library from 2.x.x to 3.x.x. The error I got is MSB4063 and MSB4064 as below:
/Users/user/.nuget/packages/xamarin.forms/3.6.0.344457/build/Xamarin.Forms.targets(4,4):
Error MSB4064: The "XamlFiles" parameter is not supported by the
"XamlGTask" task. Verify the parameter exists on the task, and it is a
settable public instance property. (MSB4064) (App.Core)
And:
/Users/user/.nuget/packages/xamarin.forms/3.6.0.344457/build/Xamarin.Forms.targets(3,3):
Error MSB4063: The "XamlGTask" task could not be initialized with its
input parameters. (MSB4063) (App.Core)
I checked and some people are able to sort it out by clean and rebuild, or by delete the bin and obj folder from the project and build it again. However, none of them work for me. Any help would be really appreciate.
This is the list of all nuget libs I have on my project. Some people also mentioned that it could be conflict between libraries using old version of Xamarin.Forms. I tried to upgrade all of them but still got the same issue.
I am on Visual Studio for Mac - Community version 8.0.5 (build 9), and I am on Mac OS 10.14.2.
Thanks.
When compiling my C#-project referencing a project cloned from CommandLine I get this error:
Error 2 The command "ClassLibGenerator.paket/paket.bootstrapper.exe"
exited with code 3
However when I use the VS-solution provided within the clone and compile the CommandLine-project there everything works fine.
Both solutions - mine and the one from the clone - contain the same project - CommandLine.
I can´t finf what the error-code means nor do I know why bootrtrapper is needed or what it actually does in this context.
Not sure if this is of any use, but had a similar problem with "paket.bootstrapper.exe exited with code 216", there were also a load of missing references (see later). This was the only SO question I saw so hopefully this may be of use to someone.
Paket is a package manager which is a kind of suped-up NuGet. bootstrapper.exe is a program which downloads the latest manager.
http://fsprojects.github.io/Paket/bootstrapper.html
What I did to fix my problem was to go to Tools->Extensions and Updates->Online and install Paket. Restarted Visual Studio, and tried to recompile. This time it resolved my missing references, but still had the 216 error. Turns out this is 32-64 bit compatability error. I downloaded the newest version of "paket.bootstrapper.exe" from
https://github.com/fsprojects/Paket/releases, overwriting the existing bootstrapper.
This got me compiling again :)
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.
I'm getting the following error:
error CS1704: An assembly with the same simple name
'Interop.xxx.dll, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null has already been imported. Try removing one of the
references or sign them to enable side-by-side.
Everything I've seen says that I am referencing two assemblies with the same name and I need to remove one of them. However, I've checked and I'm only referencing it once.
This also only happens when I'm using msbuild to build from the command line on my dev box. If I build through Visual Studio or do a clean build on our CI server I don't see this error.
I've tried completely removing all of my source and building from scratch to more closely resemble the build machine but no luck.
So it looks like I can't read today!
The project had a reference to the Interop and a COM reference that generated the "same" interop. So there were two and I just didn't search very well. I still don't understand why it worked in other places but this did fix it.
In the Error List window, the project that was triggering this error was listed in the Project column. I got around the error by doing the following:
I unloaded the listed project (right-click => Unload Project)
Opened the XML for edit (right-click the unloaded project => Edit {ProjectName.csproj}).
Searched for the offending .dll, and noticed it was listed multiple times in the XML
Removed the entire Reference tag related to the offending dll, and did so for every copy of the reference except the first one listed
The reason it was listed multiple times was because several referenced libraries used that dll. This shouldn't be a problem, in and of itself, so I'm not sure what caused this error to suddenly pop up for me. I'll update this answer if I figure that out.
In my case the duplicate entry was caused by a NuGet package reference and a direct file reference to the same assembly in the packages folder. I am not sure how the project got into this state, but unloading the project and searching the XML file for the offending assembly name resolved the issue for me.
Note that in my case this started happening after updating a NuGet package to a newer version with no other changes to the project, so this maybe caused by a bug in NuGet.
If this is a web project, are there any strong-named references to the other version there? Those won't show up as a project dependency, but will cause a run-time error like you describe. Hope that helps
I had this problem but in my case, I had an old copy placed in the current folder for the EXE loading my component, that was loaded together with the current one, that was loaded by hand from my projects folder. Deleting that old copy solved my problem.
I used Debug > Windows > Modules window to see which modules were loaded at that time and that solved my problem.
For others facing the same as me: if building via command line using property AssemblyName, it will overwrite all assemblies generated by all solution projects - in other words, you will end up with (N -1) assemblies named the same where N is the no. of projects - the startup one (which generally will generate an exe).
This happens because all build command line properties are global and overwrite any project-specific setting. See this and this.
From the msdn link mentioned above:
Global properties are properties that are set by using the
/property switch on the command line, or properties that are set by
the integrated development environment (IDE) before a project is
built. These global properties are applied to all projects that are
built by using this Engine.
In my specific case, where Jenkins is the CI tool, I ended up adding a windows batch command at the end to rename the .exe only to what I originally intended when passing the AssemblyName parameter.
For those developing UWP projects that have project references that include specifically the Microsoft.Windows.SDK.Contracts nuget package (or other dependencies that reference it), this is a common error when the version of the SDK contracts is targeting a different version of the runtime to how your project is configured.
For instance, when targeting Windows 10, version 1903:
Any dependencies or reference projects should target or at least support the same runtime version.
it is common thought process to update all NuGet packages when a new stable version is available, but this is not always a helpful practise on its own. Just because a new stable version of a package is available does not mean that you should or that you can easily use that version.
Even though this package for SDK contracts has a stable update, it is not compatible with my main project configuration, Nuget does not know this so it allows the update.
This package is specifically designed to provide windows dlls for project types that DO NOT have windows platform targeting support, it copies the same dlls that are included by the UWP targeting config. By installing later versions of the package the references from the satellite project will be included in the output along with those provided due to platform targeting, ultimately causing OPs error.
There are similar SDK and targeting packs for Windows IoT Device Runtimes, this information should help you identify and resolve those issues if you get stuck on this issue as my team often does :)
In my case, the issue was on wrong characters in the ProjectReference section of my csproj file.
Background
I have a project that references another library I maintain, which I publish as a NuGet package.
Whenever I make changes to my library, I usually reference the local dll in my project to test and make sure everything looks good before I publish the library as a NuGet package.
When testing, I just comment out the PackageReference line and uncomment the ProjectReference one so it references my local dll, like so:
<ProjectReference Include="..\..\my-class-library\MyClassLibrary.csproj" />
<!--<PackageReference="MyClassLibrary" Version="2.0.1"/>-->
Root cause
I had the slashes inverted, so I was using / rather than \ in the path, like so:
<ProjectReference Include="../../my-class-library/MyClassLibrary.csproj" />
Once corrected, the issue went away.
Try this instead: remove Interop.xx.dll from the reference section in Solution Explorer and Rebuild the project
In our case this error was shown when we had a duplicate reference inside the .csproj file (although I have no idea how this happened).
The difference to an already posted answer is that, in our case, one was a project reference and another one was direct binary reference to a dll.
Once we removed one of those, project correctly compiled.