Issues with .NET Standard 2.0 with .NET Framework & NuGet
terrajobst opened this issue · 163 comments
Summary
We've designed .NET Standard & our tooling so that projects targeting .NET Framework 4.6.1 can consume NuGet packages & projects targeting .NET Standard 2.0 or earlier. Unfortunately, we've seen a few issues around that scenario. The purpose of this document is to summarize the issues, outline our plan on addressing them, and providing workarounds you can deploy with today's state of our tooling.
Symptoms and root cause
The primary symptom is that applications crash with a FileLoadException or a FileNotFoundException. Another symptom is warnings at build time regarding assembly versions. This is due to one or both of the following issues:
- Missing binding redirects
- Missing binaries that come from indirect NuGet packages
Missing binding redirects
.NET Standard 1.x was based around contracts. Many of these contracts shipped with .NET Framework 4.5 and later. However, different versions of .NET Framework picked up different versions of these contracts, as by-design of contract versioning. As a side effect of marking .NET Framework 4.6.1 as implementing .NET Standard 2.0, some projects will now start picking up binaries built for .NET Standard 1.5 and 1.6 (as opposed to previously where .NET Framework 4.6.1 was considered as implementing .NET Standard 1.4). This results in mismatches of the assembly versions between what was shipped in .NET Framework and what was part of .NET Standard 1.5/1.6.
This can be addressed by binding redirects. As writing them by hand sucks, we added an Automatic Binding Redirect Generation feature in .NET Framework 4.5.1. This feature is opt-in. Unfortunately, it's not enabled based on target framework, but by which target framework was selected when the project was created (as the feature is turned on via an MSBuild property that is conditionally emitted by the template). In practice, this means it's mostly off if you often upgrade existing projects, rather than creating new ones.
Missing binaries
There are two primary flavors of NuGet: packages.config and PackageReference.
-
With
packages.config, each project has a config file with a flattened graph of all the NuGet dependencies. The project file in turn has direct links to all the assets. The assets are selected at install time. None of this includes indirect NuGet references coming from referenced projects. -
With
PackageReferenceeach project contains MSBuildPackageReferenceitems. The project file contains no references to any assets as the assets are selected at build time. Package restore will compute the graph of all packages, including indirect NuGet references coming from referenced projects.
The default for .NET Framework projects is packages.config. This ensures more compatibility because PackageReference doesn't support all the features that packages.config did, for example, PowerShell install scripts and content.
The only supported mode for SDK-style projects (.NET Core/.NET Standard) is PackageReference. This means that a .NET Framework project referencing a .NET Standard project ends up crossing the streams between two different NuGet models. When the .NET Standard project references NuGet packages that the .NET Framework project doesn't reference, the application ends up missing all binaries coming from those packages.
Why has this worked before? Because with packages.config, all dependencies are copied to each project's output folder. MSBuild copies them up from there. With PackageReference, we don't copy the binaries because it relies on the consuming project to see its dependencies and extract the proper asset itself. This allows the consuming project to pick up the right assets for packages that use bait & switch (which many of the .NET packages must do).
Plan
The plan is to address these issues moving forward as follows:
-
Converge on
PackageReferencefor all project types, including .NET Framework. The short-term plan for (1) is to start blocking project-to-project references in Visual Studio 15.4 that will end up crossing the streams betweenpackages.configandPackageReference. This block is UI only; you can still edit the reference by editing the project by hand. The error message will instruct you to switch the .NET Framework project toPackageReferenceif you want to reference a .NET Standard project. Referencing .NET Standard binaries or NuGet packages will not require this, it's only about project-to-project references. In later releases, we plan on providing a converter. The challenge is thatpackages.confighas features we can't offer forPackagReferenceacross the board, in particular PowerShell install scripts and content. We'll need good guidance and mitigations, if applicable. -
Ensure binding redirects are on by default. Short term, this means we need to fix our target files to make sure we turn on automatic binding redirect generation. However, binding redirects don't work well in all scenarios, when there is no application project (like unit tests or add-ins). We need to work on a plan to bring the regular “higher wins” binding policy without binding redirects. This needs a proposal and proper vetting, but it seems we've reached the point where this is necessary.
Workarounds
Regular .NET Framework projects
- Enable automatic binding redirects in the root .NET Framework application.
- Make sure your root application project doesn't use
packages.configbut usesPackageReferencefor NuGet packages- If you currently don't have
packages.config, simply add<RestoreProjectStyle>PackageReference</RestoreProjectStyle>to your project file - If you currently do have a
packages.config, convert the contents to packages references in the project file. The syntax is like this:<PackageReference Include="package-id" Version="package-version" />
- If you currently don't have
ASP.NET web applications and web sites
- Web applications and web sites don't support automatic binding redirect generation. In order to resolve binding conflicts, you need to double click the warning in the error list and Visual Studio will add them to your
web.configfile. - In web application projects, you should enable
PackageReferencelike mentioned above. In web sites, you cannot usePackageReferenceas there is no project file. In that case, you need to install all NuGet packages into your web site that any of the direct or indirect project references depend on.
Unit tests projects
By default, binding redirects aren't added to class library projects. This is problematic for unit testing projects as they are essentially like apps. So in addition to what's outlined in automatic binding redirects you also need to specify GenerateBindingRedirectsOutputType:
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>Thanks for this, things do seem a little unpolished, so it's useful to have some clarity.
Other things that currently make it painful for us to mix .net framework with .net standard are a FileNotFoundException that will make it difficult for us to migrate our internal packages in a safe way: NuGet/Home#5715 and the lack of visibility of indirect packages when switching to PackageReferences: UserVoice to convert all projects to new common project format
Is it correct that PackageReference is not supported for anything other than .net core, .net standard and UWP? See the documentation:
At present, package references are supported in Visual Studio 2017 only, for .NET Core projects, .NET Standard projects, and UWP projects targeting Windows 10 Build 15063 (Creators Update).
Hopefully that will change in future as it is an option in Visual Studio and is the workaround that you describe.
Hi @terrajobst, is there a document detailing which scenarios are supported for .NET Framework 4.6.1 and .NET Standard 1.6?
I created a net461 old-sdk project in VS2017.3 and added a .NET Standard 1.6 NuGet. The build automagically copied the required shims to the output, totalling 100 files. ✅
If I open the exact same project in VS2015 and build, the output contains only 4 files, so the shims are missing. ❌
Where do the shims come from, anyway? I was following some earlier discussions, and I know at first they were deployed via a NuGet package. But later discussions talked about some machine-wide installation. What was the final result? What do we need to deploy to a build server to enable this scenario?
Is it correct that PackageReference is not supported for anything other than .net core, .net standard and UWP?
You can use PackageReference in .NET Framework projects, but as I outlined there is a loss in certain features. For instance, if you install packages that rely on PowerShell scripts (for instance, EF6) they will no longer work. Also, packages that require content (i.e. source files that are copied to the consuming project) they will also no work.
Which NuGet package are you consuming? For .NET Standard 1.x, the package is supposed to depend on NETStandard.Library which will bring in the shims.
@terrajobst repro is here: https://github.com/0x53A/n16test
The nupkg was created calling "dotnet pack" on
https://github.com/0x53A/n16test/blob/75fcfdc0d540531c30b805e74bb239e42d13ffea/ns16lib/ns16lib.csproj#L1-L7.
The resulting package looks like this:
To reproduce my issue:
- open https://github.com/0x53A/n16test/blob/master/net461exe/net461exe/net461exe.sln in VS 2017.3 and build.
- note that /bin/ contains 100 files.
- clean /bin/, re-open in VS 2015.3 and build
- note that /bin/ contains only 4 files.
In vs2015, in a csproj targeting v4.6.2, I wanted to add a reference to Entity Framework Core 2.0, but that failed with this error:
Attempting to gather dependency information for package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0' with respect to project 'EF Core 2\NWEFCore2.Persistence', targeting '.NETFramework,Version=v4.6.2'
Gathering dependency information took 0,87 ms
Attempting to resolve dependencies for package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0'
Resolved actions to install package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0'
Retrieving package 'Microsoft.EntityFrameworkCore.SqlServer 2.0.0' from 'nuget.org'.
Install failed. Rolling back...
Package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0' does not exist in project 'NWEFCore2.Persistence'
Package 'Microsoft.EntityFrameworkCore.SqlServer.2.0.0' does not exist in folder 'C:\Myprojects\VS.NET Projects\LLBLGen Pro v5.3\UnitTests\EntityFramework\packages'
Executing nuget actions took 62,07 ms
install-package : Could not install package 'Microsoft.EntityFrameworkCore.SqlServer 2.0.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.6.2', but the package does not contain any assembly references or content fi
les that are compatible with that framework. For more information, contact the package author.
At line:1 char:1
+ install-package Microsoft.EntityFrameworkCore.SqlServer
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Install-Package], Exception
+ FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
Likely a bug in the Nuget client in 2015 (but I am under the assumption I have the latest version installed), but IMHO this should simply work as .NET 4.6.2 supports .NET standard 2.0
(edit) This does work in vs2017 15.3.x. That's not an excuse to not fix this! Many devs are on 2015 and have no plans to move to 2017 (yet) and as .net standard 2.0 is supported on .net 4.6.2, they should be able to expect this to just work.
I don't know if this is the right location to file this (likely not!), if not please point me to the repo where I should file this, thanks.
cc @forki I wonder what impact this has on Paket vis-a-vis automatic binding redirects (Paket has the option to generate BRs on demand based on the dependency graph).
@terrajobst If there's a BR already in the app.config file and you turn on the automatic BR redirection, who wins?
@isaacabraham I have no idea. this will bring interesting new problems to us.
And another problem:
Using EF Core 2.0 in a .NET 4.6.2 project: as soon as you create a DbContext derived type, you'll get this error:
System.IO.FileLoadException : Could not load file or assembly 'System.ValueTuple, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Exception doesn't have a stacktrace
Likely caused by the same issue as the ValueTuple containing assembly isn't there. This is in vs2017 15.3.x btw.
Brb, throwing some heavy furniture against the wall screaming.
@FransBouma This looks familiar: #476 (comment)
How about dropping this scenario and make it work "cleanly" with a future version instead of trying to get with the head through the wall?
Note that the binding redirection documentation is missing the critical
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>property which is crucial to making "classic" test projects work (as well as libraries loaded via reflection).
@0x53A yes, I think that's similar. The bindingredirect however kills nunit for some reason (the test is now simply not seen by it and not run).
@dasMulli Thanks for that, but I am at a loss where to add that... adding it to the bindingredirect nor the csproj etc. does make nunit work again.
And here I am hoping that after weeks of fighting with MS pre-alpha quality tooling (Where's the QA testing? We paid for this software!), this week would go smoothly. Nope
(edit) fsck it, converting to new csproj format, perhaps that gives some results.
(edit) for ref: dotnet/sdk#1070 adding the 2 redirects made nunit work again. With the new csproj format the bindingredirect isn't needed, the valuetuple issue isn't popping up, but the attribute referred by @dasMulli are required to make things work.
Man... one could start wondering what 'alpha' quality means these days if 'RTM' is this quality.
On the announcement, the "primary symptom" link is broken (via @forki )
@FransBouma I wasn't directly referring to your problem but rather pointing out that the official documentation and announcement issue lacks this information (cc @terrajobst).
For VS 2015, there is an additional extension to install for .NET Standard 2.0 support - When using NuGet 3.6.0, it will print out the link. However, I've tried it but it is currently broken anyway for most scenarios: dotnet/sdk#1539
@dasMulli oh sorry about that, but in any case it helped me a lot, so thanks for your input :)
Yeah I think 2015 is a lost cause at the moment. Thanks for referring to the nuget link, I didn't know I had to install a separate extension. In my 2015 installation it didn't mention that.
When you say
simply add PackageReference to your project file
I'm assuming this means the csproj has to use the VS2017 style csproj, as in, it needs to start with <Project Sdk="Microsoft.NET.Sdk"> and it needs to be built using msbuild 15 or the dotnet cli, right? Only working in Visual Studio is not much use for everyone (and I hope this is the majority) who use CI/CD pipelines. So this means that we can't really use netstandard nugets without converting the csproj file to vs2017 style.
@mariusGundersen all csproj format ("classic" + "sdk-style") can use PackageReference items since VS 2017 15.2. NuGet tries to detect if there is any <PackageReference> item in the project or if there is a packages.config in the project to determine which "restore style" is to be used.
However, if neither of those are present, the <RestoreProjectStyle> can be set to PackageReference to enable all features of projects using this style. This then enables transitive dependencies from referenced projects also using PackageReference. The "sdk-style" (<Project Sdk="Microsoft.NET.Sdk">) projects already set this by default.
So I need to install the latest nuget client on the build server to be able to use <PackageReference>? And I guess that as long as the project file is still classic style it needs the <Reference> and <HintPath> to work?
Thanks for the repo, we'll take a look.
Make sure you have the latest NuGet client for VS 2015. It looks your client doesn't know that .NET Framework 4.6.1 supports .NET Standard 2.0. If the error persist after upgrading, I'd file a bug in the NuGet org (https://github.com/NuGet/Home/issues/new).
@isaacabraham and @forki
I wonder what impact this has on Paket vis-a-vis automatic binding redirects (Paket has the option to generate BRs on demand based on the dependency graph).
My recommendation is: don't add BR via a package manager. We've worked with the NuGet folks to disable their BR generation as well. It should be generated during build, because that's the only place where all the necessary context is available. If anything, I'd consider making Paket add the AutoGenerateBindingRedirects property to the project file if it isn't set already.
Eventually, I'd like the desktop binder to do the right thing here, but we'll see whether we can actually pull this off...
If there's a BR already in the app.config file and you turn on the automatic BR redirection, who wins?
The automatic binding redirect feature will attempt to merge them. Generally speaking, manual BRs will be honored and win.
How about dropping this scenario and make it work "cleanly" with a future version instead of trying to get with the head through the wall?
What would you do differently from what I outlined in the plan above? To me, the plan is precisely what you're asking for.
Excellent point. Fixed.
When you say
simply add PackageReference to your project file
I'm assuming this means the csproj has to use the VS2017 style csproj
No, you can use non-SDK style projects with PackageReference.
@terrajobst when you say "No, you can use non-SDK style projects with PackageReference" does this mean I can just delete my packages.config and then in my .csproj remove the hint paths and replace with PackageReferences and it'll just work (provided I'm on the correct NuGet version)?
Or is there some other magic you need to do to use PackageReference with non-SDK style projects?
How about dropping this scenario and make it work "cleanly" with a future version instead of trying to get with the head through the wall?
What would you do differently from what I outlined in the plan above? To me, the plan is precisely what you're asking for.
I appreciate the response. Well yes you are dropping packages.config support. But I meant dropping the compatibility of net461 with netstandard20 from the compatibility table and remove all the special handling around this. This would be the honest way of saying: "Well the runtime did not ship with the proper support for netstandard20 but a future version will". What are the reasons which justify the amount of pain you put everyone through and the amount of effort it generates everywhere (not only internally in Microsoft but also externally like in Paket). There must be really important reasons to have this single compatibility connection but I have no clue what they are.
Could this been fixed with net462 or net463? Maybe I'm missing something here.
when you say "No, you can use non-SDK style projects with PackageReference" does this mean I can just delete my packages.config and then in my .csproj remove the hint paths and replace with PackageReferences and it'll just work (provided I'm on the correct NuGet version)?
Two options: remove the packages.config and convert all package references by hand as explained above. You can also control the default for .NET Framework works via Tools | Options | Package Manager | General.
But I meant dropping the compatibility of net461 with netstandard20 from the compatibility table and remove all the special handling around this.
Believe me, no one on my team is keen on on the way the net461 support story has unfolded. In a sense, what you're asking has already been implemented: .NET Framework 4.7.1 will ship with full built-in support of .NET Standard 2.0. The challenge is that (1) it hasn't been shipped yet and (2) many of our customers will not be able to upgrade immediately because the target environment is outside their control. The option was to support it the best we can or can it altogether. Yes, this unfortunately requires jumping through hoops but at least there is something app developers can do. If you fully control the environment, by all means, jump to .NET Framework 4.7.1.
Actually we often set it to make sure nuget/build does not mess with what we intended (or at least to know when that happens). As double-entry bookkeeping if you will. Now this usecase is basically broken - or in some sense you are basically removing all use cases of the redirects if you make the automatic all the time.
The problem with double bookkeeping is that automatic binding redirect generation has to assume the project owner knows best and has to honor the BRs that are present. I don't know Paket well enough, but with NuGet we had the issue that NuGet assumed that the same package & version will have consistent assembly versions and not generate redirects based on the referenced assemblies but based on whether package versions differed. If Paket gets it right a 100% then there is arguably nothing against it, but I'd also argue nothing in favor of it either. Outside of .NET Framework you already rely on the binding behavior that higher wins. A generated app.config with the right redirects will do the same, so I don't see a reason why a checked in copy with the project is helping. I just think it causes noise and adds potential for conflicts...
If what @terrajobst is saying is that simply adding that single element to a vbproj, fsproj or csproj magically fixes all binding redirects, all the time, then I'm not averse to using that instead and deprecating Paket support for BRs. But only if this works consistently and can be applied to e.g. net452 projects running on old MSBuild project format.
magically fixes all binding redirects
think about what that means. It means there are effectively no binding redirects anymore.
So in some sense the feature is gone.
Doesn't it just mean that the redirects are calculated by the runtime to just promote all assemblies to the version that actually is being used?
that's effectively the same thing, right? It "calculates a redirect to what it actually uses" - what sense does that even make? It's not "redirecting" anything or checking against an external file if what it uses is what was intented.
I may think of binding redirects slightly differently to you. I'm not sure that I do, but your last questions, indicates a slight difference I think.
I don't think of it as impacting an assembly, I think it impacts the reference to the assembly.
The binding redirect in an app config file, is a policy statement to the runtime. It says to the runtime, when after applying all versioning policies you see an assembly reference in the range MIN to MAX, go and set the version of the reference to X.
What the AutoGenerateBindingRedirects build property does, is to calculate during the build the highest version number of an assembly by examining /r: assemblies and their referenced dependencies. If it sees multiple values for an assembly version, it generates a binding redirect in the app-config to ensure that users of the application doesn't see assembly load errors, because of version mismatches. It then requires the developer to ship this 'highest referenced version' with the app. The build will of course ensure that this is the version copied to the output directory, to make it easy for the developer to identify the correct dll to ship.
I hope this helps, it is for sure how I think of this stuff.
Kevin
Regarding Unit Test projects (as I already mentioned in dotnet/sdk#901):
I'm using VS2017 15.3.3 and .NET Core 2.0.0 SDK. Solution consists of:
- Project A - .NET Standard 2.0 class library; referencing Newtonsoft.Json via Nuget
- Project B - .NET 4.6.1 unit test project; referencing A
I'm hitting FileNotFoundException in B. As a workaround, I put
<PropertyGroup>
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
in B's project file. Using <RestoreProjectStyle>PackageReference</RestoreProjectStyle> has side effect though: all tests in B disappears from Test Explorer window. To fix this issue, I had to upgrade test adapters and test framework via nuget as described here.
Is this intended behavior of package reference or a bug? Either way, I think others might experience it, so I would suggest to update workaround info above.
yes I do understand redirects and their influence on the runtime ;-)
I never said it would influence an assembly.
I think it boils down to the recurring theme that I (and others) happen to use it in a different way than many MS employees may do. For me it makes absolutely no sense to let the build automate it, because then we could just throw it away completely or at least gitignore it or something.
For me it's a way for users to make sure the the build (and deploy!) process is doing the right thing and in the end we have the correct version of the assembly loaded into our program.
This is especially important when you have a bigger solution and many dependencies. In such cases we often saw just one version of an assembly (like FSharp.Core/newtonsoft) win and then in the end we had MissingMethodExceptions all the time.
We then made sure package management worked and only uses one package in the whole repo - but even that wasn't enough. So binding redirects where needed so that at least at app start you know if things are still sane.
Make sure you have the latest NuGet client for VS 2015. It looks your client doesn't know that .NET Framework 4.6.1 supports .NET Standard 2.0. If the error persist after upgrading, I'd file a bug in the NuGet org (https://github.com/NuGet/Home/issues/new).
here's the thing, in vs2015, I have nuget extension v3.5.1484 installed, but if I browse to the gallery in vs2015 and search for 'nuget' I see it offers v3.4.4.1321. vs 2015 itself doesn't say I need to update the client. The gallery states it's been updated on 6/3/2016 (that's more than a year ago) and the one in vs2015 has been updated on 10-11-2016.
This is in vs2015 update 3. (v14.0.25431.01). AFAIK there's no update 4 for vs2015, and the build of nuget client for vs2015 is very old. I can now go over to the nuget repo and have an unpleasant conversation with the folks over there, but I think there's something else not right: where is the updated client for nuget for 2015?
TIA
@KevinRansom the problem is that you might still implicitly break something e.g. imagine you have two projects A and B. A depends on V1 of dep, B depends on V2. At runtime you pick V2, as it's the higher one. But V2 introduced breaking changes compared to V1 - either behavioural (different code paths), or structural (different interface, change of method signatures).
What happens at runtime when Project A tries to call a method that was in V1 but doesn't exist in V2 any more? Boom - MissingMethodException.
Is it something other than : “The highest version of the assembly discoverable during the build”?
yes definetely. because that is often just a mistake. Consider you have 100 projects in your sln. All of them use Newtonsoft (which is not that unlikely). Now one upgrades it version from 5.x to 10.x for some (maybe even good) reason.
Now 99 compile against v5 and one against v10 - these are clearly not compatible in any way. It's just a matter of time until something crashes. And there is no resolution to this. "Highest" is as good as "pick one at random" here.
What uses can do is add an binding redirect to the app project that ensures that everything points to v5 (because that's the one we blessed). If the build now ships v10 then you know this "earlier" during deploy and not during on call night hours.
Of course even this is not a perfect solutions since there are still endless ways to mess up, but practice showed that these tricks work very effectively against common human errors.
Yes I used a caveat, but so did you::
Of course even this is not a perfect solutions since there are still endless ways to mess up, but practice showed that these tricks work very effectively against common human errors.
@forki
I don't disagree with you, I know it sounds like I do, but I don't. I think the position you take, where the developer of the app is the only one who knows the right answer is a decent position to take.
I think I would take a different one though. I would suggest that the most common position is that future versions of useful assemblies will be compatible and incompatibility will be a bug in the library that will be quickly fixed, if found quickly.
I could be wrong ... but I know that we try hard to maintain compatibility and to respond quickly when we mess up.
Major releases that introduce breaking changes is a completely normal thing that happens, all the time. That's not a bug and might never be fixed.
Sigh !!!! I wish I worked in a world where I could get away with that, it must be lovely.
Sigh !!!! I wish I worked in a world where I could get away with that, it must be lovely.
In my experience, breaking changes (potentially each minor version) is the default state if the maintainers don't explicitly promise binary compat.
Sad, but realistic.
Just my two cents and a different take on the app.configs: I like to have binding redirects in the source-tree version of my app.config, because that means I can copy-paste an app.config from source control to production.
Instead I would want the build to verify and fail if the app.config is not compatible with the actual binary output (e.g. if the app.config contains 5.0 but the bin directory contains 10.0).
This is not possible with nuget because dependencies float and so the source tree would be modified on each restore.
But I think this also slightly shows the different philosophies between nuget and paket:
Paket tries to resolve dependencies once and then locks them. Later restores will not modify this state.
Nuget instead resolves each restore, potentially different between runs, making reproducable builds impossible, and then has to implement hacks like generating an app.config at build time to hopefully make things run.
I've said it before, but just wanted to repeat myself: I didn't move our work solution to paket because paket is so great (well, it actually is). I moved it because nuget is so bad.
Binding Redirects
think about what that means. It means there are effectively no binding redirects anymore. So in some sense the feature is gone.
You're the first person I encounter who thinks of the .NET Framework exact match binding policy as a feature :-)
Would you go so far and say that all the other .NET runtimes (CoreCLR, .NET Native, Mono) are missing a feature, because they will happily bind to the version deployed by the application -- so long the version is equal to or higher than the version that is requested?
Doesn't it just mean that the redirects are calculated by the runtime to just promote all assemblies to the version that actually is being used?
Not quite. The way binding redirect works is like this: when an assembly load is requested, the binder applies policy. This includes the runtime unification table, binding redirects, publisher policy stored in the GAC, as well as the AssemblyResolveEvent (not sure about the order). This policy might change the assembly version. After the version is determined, the binder will use the probing locations to find the excact version. If no assembly in that version is found, you get the canonical FileLoadException.
The way we see the "higher version wins" policy is like this: the application can specifcy a set of probing locations. By default, this only includes the application folder. The binder will then load the highest assembly version among all probing locations that satisfies the assembly load request. Allowing for multiple probing locations allows applications with plug-ins (like VS) to coordinate the load when multiple plug-ins share an assembly (like JSON.NET). In that case, the only sensible thing is to load the highest version across all plugins because it resolves plug-in activation order issues. Of course, one could argue that the best way is to load all shared assemblies side-by-side so that each plugin gets its own copy, but that requires multiple app domains or assembly load contexts and doesn't work in all cases where types need to be exchanged.
@KevinRansom the problem is that you might still implicitly break something e.g. imagine you have two projects A and B. A depends on V1 of dep, B depends on V2. At runtime you pick V2, as it's the higher one. But V2 introduced breaking changes compared to V1 - either behavioural (different code paths), or structural (different interface, change of method signatures).
That is true but binding redirects cannot solve this issue because there is no version that will work with both A and B. The application is toast. Now, I'd argue the only sensible thing for the app is to load V2 in the hopes hat A wasn't affected by the breaking change introduced in V2.
Issues
I'm not aware of this issue. Did you uninstall the packages first / did you migrate the contents of the packages.config file into the PackageReference elements?
Ah, I see. Seems like it hasn't bee released through the gallery yet. Go to https://www.nuget.org/downloads and select VS 2015 VSIX v3.6.0. I'll follow up with the NuGet team to see why 3.6 wasn't pushed yet.
@terrajobst It would be great if you could explicitly clarify the requirements for a) modifying projects and b) building projects.
For example, there is no updated download for VS2013 on https://www.nuget.org/downloads, so I assume that only VS2015 and up are supported?
a) Modifying projects:
To install a .NET Standard 2.0 (or 1.6) NuGet into a project, the package manager needs to know about the mapping, so it needs an updated nuget extension. That one seems obvious.
b) building projects:
after I have installed the package into the project, all required information should be inside the project file, so do I also need to update the buildserver? I would expect not.
Can I still build with VS2013 after I have installed the package using VS2015 with updated nuget extension?
It is ok if really old tool versions like VS2013 are no longer supported, but please make it explicit which scenarios do and which don't work.
That is true but binding redirects cannot solve this issue because there is no version that will work with both A and B. The application is toast. Now, I'd argue the only sensible thing for the app is to load V2 in the hopes hat A wasn't affected by the breaking change introduced in V2.
Correct. But I think there are two other points to this:
- With explicit BRs, you can control which direction you go. Perhaps you don't want to go upwards to the highest version, but prefer to stay at the lower one.
- With explicit BRs, until you put the BR in, AFAIK you will immediately get a runtime error (the canonical
FileLoadExceptionthat you mentioned). It's not perfect, but I'd rather have that and know as soon as it happens - at which point we can make a decision to upgrade our solution or not - rather than risk finding out two months later when my code goes live and a bug appears.
There's value in both approaches. However, my instinctive feeling is simply that this kind of silent "natural selection" of different assembly versions is going to come back to bite all of us. Perhaps I'll change my mind on this as the discussion progresses, or not :-)
@forki, @terrajobst, @isaacabraham
Yes coreclr is missing a feature.
A bit of history on why downward binding even exists on the desktop:
Before we shipped V1.0 of the CLR there was a scenario that we cared about:
An Application AppA shipped with a dependence on AssemblyB V1.0.0.0.
An Application AppB shipped with a dependence on Assembly B V1.0.1.0 and publisher policy Upgrading v1.0.0.0 refs to V1.0.1.0 all policy assemblies and dll's would be installed in the GAC
Now V.1.0.1.0 of B was slightly incompatible with V1.0.0.0 and because of the pub policy AppA was broken.
We actually had in Windows tooling to inject a binding redirect into the app.config for App A, pushing the Binding back down to 1.0.0.0 (it was upgraded by the policy assembly) downgraded again by the binding redirect.
The above scenario was why binding redirects, were designed.
Notice:
- Publisher policy was deprecated even before we shipped V1.0 of the CLR so the scenario is essentially invalid "as designed"
- The tooling to add binding redirects was removed by the time Clr 2.0 was released, because they weren't actually useful now that policy was deprecated.
- In the intervening years app.config binding redirects have become a general purpose binding unification facility.
Today there is still a scenario that is easy on the desktop and impossible on the coreclr. The coreclr binding policy of not allowing downward binds is what makes it impossible on the coreclr, binding redirects solve it on the desktop CLR
Application A
- Depends on Library B which depends on Library D V1.2.0.0
- Depends on Library C which depends Library D V1.1.0.0
Library C is unable to work with V1.2.0.0 because of a compatibility bug.
Library D could successfully work with Library V1.1.0.0 but the author was foolish and compiled with a higher than necessary version of the library and so an Application cannot successfully compose Library C and Library D.
On the desktop a downward binding redirect would allow an application to compose these libraries by fixing the references to 1.1.0.0. On the Coreclr, there is no combination that will work.
There are two possible solutions:
The first is very hard:
- Educate the ecco-system to always reference the lowest version necessary of referenced libraries.
- Ensure that developers quickly address compatibility bugs
The second is easier:
- Change the coreclr to bind to the local assembly regardless of version number. The developers job is to deploy the correct and tested dll, since the bind is not from the shared framework the version check is not really that useful, it either works or crashes the app.
Or add binding redirects ....... No please don't do this that would make me sad
If I had a vote, my preference would be educating the ecco-system to do the "right thing". However, right now there is a valid binding scenario on the desktop that is impossible to replicate on the coreclr.
Anyway that is my 2 cents.
Kevin
To reference a library that targets .NET Standard 1.5 or higher, you need to install the .NET Standard Build Support extension for the .NET Framework from https://aka.ms/netstandard-build-support-netfx
Well, I guess that answers part of my questions above.
Opening the msi in Orca, I can see the shims (which answers my other question from above, where the shims actually come from) and a few task dlls / targets files.
Imho this is the worst possible deployment model - now I need to update all buildservers and all developer environments, but if I don't they will fail silently.
The previous model, where the shims were deployed with a nuget package (NETStandard.Library.NETFramework) was slightly better from that perspective.
I have a test project (VS2017.3 and after making the changes listed I still get
Reference required to assembly 'System.Runtime, Version=4.0.20.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' containing the type 'ValueType'. Add one to your project.
How do I add this to my project?
Also I can't upgrade any NuGet Package from 2.2 to 2.3.2 without getting too many errors to list. I am targeting 4.6.2 and would like to move to 4.7 and latest CodeAnalysis packages.
I'm not aware of this issue. Did you uninstall the packages first / did you migrate the contents of the
packages.configfile into thePackageReferenceelements?
Oh, now I realized where I made a mistake. My steps to reproduce the issue were:
- Create new solution with new unit test project.
- Build solution.
- There is test method
UnitTest1.TestMethod1()generated from the template. It should be visible in Test Explorer. - Delete
packages.config. - Close VS.
- Edit csproj (vbproj in my case) and put
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>there. - Open VS.
- Rebuild solution.
- There is no test method in Text Explorer anymore.
My problem was: I didn't explicitly reference any Nuget package in test project yet, so I thought there is no need to migrate anything from of packages.config into the PackageReference elements. But there are 2 packages referenced by default in packages.config: MSTest.TestAdapter and MSTest.TestFramework. Migrating them manually fixed the problem (so did referencing them via Nuget Manager as I wrote previously).
Sorry for confusion, my mistake.
I just opened an issue in the Xamarin bug tracker here but it seems to be specific to netstandard. I basically converted a Xamarin PCL to netstandard and only using a method from the Newtonsoft.json NuGet package makes the android project throw a compilation exception
Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. Perhaps it doesn't exist in the Mono for Android profile?
Is this issue the cause of JamesNK/Newtonsoft.Json#1423?
I logged issue #504, but this maybe seems like a more relevant place to comment.
I have done a bit of playing around, trying to follow the workaround instructions at the top, but even so it still doesn't seem to work.
Here is what I have now done to try and make it all function.
- Created a new Class Library (.NET 4.7.1)
- Converted the project to the new VS2017 style
<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Library</OutputType>
<RootNamespace>MyProject</RootNamespace>
<AssemblyName>MyProject</AssemblyName>
<TargetFramework>net471</TargetFramework>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="NETStandard.Library" Version="2.0.0" />
</ItemGroup>
<ItemGroup>
<Reference Include="System" />
<Reference Include="System.Core" />
<Reference Include="Microsoft.CSharp" />
<Reference Include="System.Data" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="NETStandard2.csproj" />
</ItemGroup>
</Project>- Added nugget package for NetStandard.Library v2.0.0
- tried to build, fails
- Manually add reference to .netstandard.dll
- Build Succeeds
Firstly, I thought that 4.7.1 was supposed to play nice with NetStandard 2.0, but secondly I am still having to add the manual reference which is surely what the nuget package is supposed to be about.
Is there something that I have got wrong from the instructions above - if so, I can't work out what it is.
If anyone has some contact with the team maintaining the Microsoft.Bcl.Build package, there is an error in the package where it checks for the existence of packages.config.
See NuGet/Home#2913
@terrajobst When you said...
My recommendation is: don't add BR via a package manager. We've worked with the NuGet folks to disable their BR generation as well. It should be generated during build, because that's the only place where all the necessary context is available.
... are you suggesting that we check the "Skip applying binding redirects" checkbox here:
The automatic binding redirects is a tooling feature to just generate the redirects in the config file, right? I recall it not working for me in some situations for whatever tooling reason and this caused some pain in the past.
Really, what I would desire on this point is a way to tell the runtime to use whatever name-matching assembly I have thrown into the bin directory. I do not want to the runtime to care about versions - whatever assembly lands in my bin directory is what I want the runtime to use (and if there are multiple, I expect it to error and tell me to get my stuff straight). I do not want "higher wins" or any other "smart logic", I just want "I literally put a DLL file with the right name in the bin directory, just use that to serve your human masters, machine".
@terrajobst
If you currently do have a packages.config, convert the contents to packages references in the project file.
Please update this guidance like below to get the right behavior:
- Uninstall all the current packages from nuget manager ui or pmc console.
- Then add all packages in PackageReference format in csproj file. The syntax is like this:
<PackageReference Include="package-id" Version="package-version" />
There seems to be a problem with using Fakes in this new world. If you try to build Fakes for something exposing System.Net.Http.HttpClient, then it fails to generate. Has anyone found a solution for this?
Error CS0430 The extern alias 'snh' was not specified in a /reference option [D:\Files\Visual Studio 2017\Projects\FakesTest\FakesTest\obj\Debug\Fakes\bcldsc\f.csproj] FakesTest D:\Files\Visual Studio 2017\Projects\FakesTest\FakesTest\f.cs
@Blackbaud-JonathanBell Exactly the same issue for me for the System.Net.Http.HttpClient. But also it seems to be that System.Composition.CompositionContext is affected. Any thoughts on this?
The issue appears to be because the generated fakes project produces code that references these assemblies w/ an extern alias --- extern alias snh;. The generated project references these assemblies like System.Net.Http which are in this weird transition state and defines the alias for it, but since those assembly references actually get ignored due to this transition magic, then the alias isn't recognized.
No clue how to fix it ...
Maybe I am wrong, but it seems to be an compiler issue, isn't it?
From what I read you can pass a flag to the compiler telling it the alias/reference like /reference:snh=System.Net.Http.dll. This seems not to be the case. Is there an option to pass this flag to the compiler during Fakes generation?
Could it also be that the compiler does not know which System.Net.Http version to take, when it generates the Fakes? I am using System.Net.Http 4.3.3.0 in a .NetFramework project with .Net 4.7, but maybe there are dependencies left to version 4.0.0.0. I do use <bindingRedirect>, though.
Any thoughts?
We have recently migrated a solution from .NET 4.5 to .NET 4.6.1. Many of the nuget packages we consume are now available as netstandard2.0 which is chosen in preference to net45/net46. This is a breaking change for us as we have a solution containing both C# and C++/CLI projects. The latter can't reference netstandard2.0 libraries. Is there any way to force the selection of net45/net46? (e.g. project change). We are still using packages.config.
is there a way to force a certain TFM to be used for a packge in a project?
There isn't a way to set the TFM per package, only the project TFM is used.
@emgarten in this case they want to target 4.6.1 but want want the .net framework asset from the package as opposed to netstandard for their C++/ CLI project.
@terrajobst any reason C++/CLI can't be made to work with netstandard?
Many of the nuget packages we consume are now available as netstandard2.0 which is chosen in preference to net45/net46
This shouldn't happen.
If a project is net461 it will favor package assets in this order:
- net461 (exact match)
- net45 (same framework)
- netstandard2.0 (not the same framework, but compatible)
netstandard2.0 would only be used if zero net* assets were available in the package for that asset type. Note that assets are selected individually, so if build has net461 assets but lib only has netstandard2.0 assets then you will still get netstandard2.0 lib assets. It is up to the package author to use the same frameworks for each asset type to make this consistent.
This is true for both PackageReference projects and for packages.config projects.
@davidjward30 sounds like a .NET Framework asset in a package should be preferred over a .NET Standard asset. Is that not what you are seeing?
@Petermarcu @emgarten I've just double checked and I think the problem lies around "portable-net45+win8+wp8+wpa81" which does not appear in your list above.
If I take a .net 4.6.1 framework project (packages.config) and install System.Collections.Immutable 1.4.0, these are the options:
netcoreapp2.0
netstandard1.0
netstandard2.0
portable-net45+win8+wp8+wpa81
.netstandard2.0 is being chosen, where I would expect the last one - particularly as you stated that net45 (same framework) is above netstandard 2.0.
FrameworkNuget.zip
Note that System.Collections.Immutable 1.3.1 offers just
netstandard1.0
portable-net45+win8+wp8+wpa81
In this scenario, portable-net45+win8+wp8+wpa81 is chosen. So in summary, upgrading to System.Collections.Immutable 1.4.0 is a breaking change for us.
@emgarten how do the portable TFM's map into the picture? Is this a case where they were mapped to .NET Standard so .NET Standard is winning?
Just to summarize what @davidjward30 is pointing out:
1.3 had:
netstandard1.0
portable-net45+win8+wp8+wpa81
1.4 had:
netcoreapp2.0
netstandard1.0
netstandard2.0
portable-net45+win8+wp8+wpa81
So 1.4 added:
netcoreapp2.0
netstandard2.0
and netcoreapp2.0 is winning over portable-net45+win8+wp8+wpa81
Should 1.4 have included assets for each specific TFM it used to support in order to prevent this from being a breaking change because portable isn't treated as more specific than .NET Standard?
@davidjward30 the workaround for this is to modify the hint path in your csproj file to reference the portable folder instead of the netstandard2.0 folder in the package. For packages.config projects it is easy to override the tfm selection this way.
portable-* frameworks are the lowest priority when selecting assets, which is why netstandard2.0 is selected from 1.4.
The reason portable-net45+win8+wp8+wpa81 (profile 259) wins over netstandard1.0 is because that portable framework is a special case and able to install netstandard1.0 packages. The table of these portable frameworks with netstandard equivalents is here: https://github.com/dotnet/standard/blob/master/docs/versions.md
I can see how this is a problem for C++ projects, but for most users netstandard2.0 should be a larger surface area over the legacy portable profile 259 unless I'm missing something.
We have a fairly large codebase of 150+ projects. The workaround of modifying the hint path would probably have to be scripted and I'm not sure how long we could continue like that. Is this a workaround we would have to live with indefinitely? We also have plans to move to packagereference
@davidjward30 you could try updating all references through an msbuild props/targets file that fixes the hint paths.
I see this with .NET Standard 1.4 projects as well using PackageReference. I have a JavaScript UWP app using a Windows Runtime Component which references the .NET Standard libraries and the Nuget dlls don't get copied as part of the build.
Can I update the UWP JavaScript project which default template used package.json to use PackageReference or is that only for pure .NET projects?
Any ideas how to fix RevenantX/LiteNetLib#120 above? The binding redirects didn't help (or I did something wrong).
I responded to the issue. Your issue has definitively nothing to do with this issue here as you're using .NET Core and .NET Standard. Binding Redirects are a .NET Framework only thing. It looks like the package you're consuming is authored incorrectly.
I see this with .NET Standard 1.4 projects as well using PackageReference. I have a JavaScript UWP app using a Windows Runtime Component which references the .NET Standard libraries and the Nuget dlls don't get copied as part of the build.
Can I update the UWP JavaScript project which default template used package.json to use PackageReference or is that only for pure .NET projects?
I haven't looked into UWP and JavaScript consuming a managed WinMD. Are you using a project-to-project reference between the JavaScript project and the C# UWP WinMD project?
@terrajobst Yes, I have the WinMD component project referencing the .NET Standard component, and then the JavaScript UWP project referencing the WinMD component project.
@terrajobst ah thanks, I wondered if it was relatable to this one! Appreciate the help!
After moving to PackageReference (and toying with AutoGenerateBindingRedirects and GenerateBindingRedirectsOutputType), I am still running into a FileNotFoundException.
I am using the Pkcs11Interop NuGet package, which requires netstandard13 or net4. It is referenced from LibraryProject, which is netstandard2. That project, in turn, is referenced from WebProject, which is net471.
When building and running WebProject, it outputs Pkcs11Interop.dll, but at runtime it tries to load Pkcs11Interop.NetStandard.dll!
Which DLL should be used? I would assume the netstandard one, as the direct consuming project is netstandard.
How do we get the compile time and runtime behaviors to play nice?
Edit: It seems likely that this happens for all similar packages, but that the problem usually stays hidden because the file names are usually identical.
Still hitting this in 2018. What's the plan to make this suck less?
Ditto
The short-term plan for (1) is to start blocking project-to-project references in Visual Studio 15.4 that will end up crossing the streams between packages.config and PackageReference
Visual Studio 15.5.7 here and there is still no block in the UI to prevent you from doing that crossing.
I added the RestoreProjectStyle without taking too much time to understand it properly after finding it here while I was starting my first project with .Net Standard (thanks for it anyway @shanselman :) ). In fact I didn't realize I had to get ride off the packages.config file and reinstall all my NuGets by adding references back to the .csproj instead.
So now back to get ride off packages.config to fix my solution and crossing my finger to not hit any of those limitations and... Oh wait... of course I have packages that use a powershell script, which is not supported yet!!!
If at least the mentioned block in the UI had been there I would have noticed I did something wrong. Instead I learnt about that issue the hard way!
I have been waiting for almost 2 years prior to give a try to .Net Core and .Net Standard, thinking it will give them the required time to get mature. Looks like I was wrong and my only workaround now seems to back off .Net Core in my entire solution.
i share @ggirard07 sentiment.
I tried netstandard and hibrid project format approach since mid 2017 and it has way too many gotchas, it's a shame because the new project system is so much better, but this friction does not really allow incremental upgrades of solutions, maybe it's not meant to be, but it's a shame 😄
I am new to Visual Studio 2017 and getting a warning in my xamarin project as below
Warning NU1701 Package 'ZXing.Net.Mobile 2.3.2' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Please help me to resolve this issue.......a lot has been suffered by me on this.Please help
@pankajmishra743 your project is targeting .NET Standard 2.0, but ZXing.Net.Mobile is only built for .NET Framework 4.6.1, worth asking the package authors as this issue isn't the place to get help for things like that.
Also worth reading https://docs.microsoft.com/en-us/dotnet/standard/net-standard to familiarize yourself with what .NET Standard is. Scott Hanselman also has a pretty good blog post that summarises (or did summarise, for 2017) the state of .NET Standard/Core/Framework/etc: https://www.hanselman.com/blog/WhatNETDevelopersOughtToKnowToStartIn2017.aspx
Hitting this after converting a .net framework console exe to the new sdk format even though that is supposed to set up the binding redirects automatically. At least I assume I am, a MethodNotFoundException from a referenced .net standard project when it tries to call out to a DLL in a nuget package even though that DLL is in the output folder.
I think it may be related to the ValueTuple shenanigans where the referenced library uses v1.3.x and the consuming library uses v1.4.0
I know I am joining this late but the argument that .NET 4.7.1 in some way provides a solution is not satisfying given that we have very recently been told by Microsoft that:
1- For Azure VM scale sets there are no plans to support 4.7.1 with Windows Server 2016
2- For Azure Cloud Services there are no plans to ship 4.7.1 with Web/Worker roles
@FransBouma I had the same problem using NetStandard.Library v2.0.1: The Assembly Binding Log Viewer (aka fuslogvwr) tell me that the assembly loader was unable to load 'System.Threading.Overlapped, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because cannot find this specific version of this assembly.
The same assemly was available with higher major / minor version numbers.
I had this problem for other dlls.
The 'Il Disassembler' (ILDasm) show me that NetStandard.Library v2.0.1 references versions numbers 0.0.0.0 for many other dlls:
To resolve this problem I had to add some binding redirect to my app
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Threading.Overlapped" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>I will evaluate use of AutoGenerateBindingRedirects.
This problem reported by a user of one of my libraries here: mattjohnsonpint/TimeZoneConverter#16. Note that the binding redirect isn't an option since strong naming is not a thing for me, per .net core guidance here, and binding redirects do not work without a strong name token (I think).
@terrajobst - I'm confused by the workaround mentioned at the top. Should I just be able to add <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> to my .net standard class libraries that are published to nuget? I experimented locally, but it doesn't seem to work.
Manually adding a binding redirect in the end-user application does work, but no amount of fiddling with the settings on my side seems to force a binding redirect be created in the end-user's application when they pull in my packages. What am I missing?
Thanks.
-Matt
This setting needs to be set in the project that packages are installed into.
@sandersaares - tried that. Got bindings generated for Newtonsoft, but not for my library.
Is it just me, or is the migration path from Framework to Standard/Core (anything, 1.x, 2.x, etc) a maze that, personally, I'm finding fairly difficult, at best, to navigate, if not downright confusing. In my case, I want to dive into potentially a Roslyn compile time code generation analyzer, but I'm finding that the minimum requirements for that are at least .NET Standard 1.x? Perhaps, it seems there is a plausible bridge from Framework 4.6.x targeted projects along these lines? Or at least from my Analyzers project(s), per se. Thoughts? Suggestions? Recommendations? Thanks!