Zend Project Migration - zend-framework

i have a Zend Framework project and i need to know which framework and version they use. also is that mandatory to migrate the project from Zend to laminas. having no idea to what to do.

You can find the current version in Zend_Version::VERSION constant (there will be the same, but namespaced for ZF2 and ZF3 I believe).
Also migration to laminas is not "mandatory". It's just that Zend Framework 1/2/3 is no longer maintained.
You can find community maintained forks for older versions (like diablomedia/zendframework1)

You can find the version of the framework and plugins in composer.json file in the application folder

Related

What is the best approach to read from both Web.config and appsettings.json in a .NET Standard library?

We have an old .NET Framework nuget package built with .NET Framework that reads settings from Web.configs files on .NET Framework projects using the ConfigurationManager.AppSettings class. Now, we need to migrate it to .NET Standard to be able to use it on .NET Core projects also.
Is there an elegant way to try to find and read settings from both Web.config files when running in .NET Framework, and from appsetting.json when running on a .NET Core project? Does it make sense?
Also, it makes sense to have 2 different nuget packages, one for use only on .NET Framework projects and another to use only in .NET Core projects?
The main goal is to read setting independent of the .NET version it is running on.

NuGet Framework Targeting in Squirrel

I'm trying to better understand the proper use of .NET Framework version targeting in the project's NuSpec file, as relates to Squirrel.
For example:
<file src="bin\Release\*.dll" target="lib\net472\"></file>
Does the version specified here affect Squirrel's operations at all? Or is it a NuGet-specific construct only?
What does it mean when we say .NET 4.8 is now supported?
The behavior by NuGet is driven by the compatibility map of the frameworks.
.NET Framework is mostly backwards compatible, so NuGet has built on top of that, when your package declares that it targets net472, net48 as the next evolution is acceptable.
NuGet will allow this package to be consumed in .NET Framework 4.8 projects.
See more for .NET Framework version compatibility.
See more on cross platform targeting libraries, which talks about the multi targeting concept.

NuGet package not installing in .NET Framework

I have created .net standard library project and I have created nuget package for this library, Now I need to install this package in both application .Net Core and .Net Framework4.5. Working fine in .Net Core but while installing .Net framework project it was showing below exception.
You are trying to install this package into a project that targets '.NETFramework,Version=v4.5.2', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
Please let me know the right approach to resolve this.
The library that you have created targets .NET Standard 2.0, as stated in your tags. .NET Framework 4.5.2 does only implement .NET Standard up to version 1.2, that is why the assemblies are not compatible.
You should change your library to a .NET Standard version that is implemented by both .NET Core and .NET Framework or upgrade your .NET Framework version accordingly.
You can find the version mappings here, credits to #Matt Ward for providing the source.

Which lib folder should I use for my portable library targeting net45, asp.net core 5.0 and windows 8?

I am currently developing a portable library in C# that I want to publish on the NuGet official feed. I have published assemblies as NuGet packages before, but they were written against a single framework (.NET 4.0).
Now I'm confused how I should organize my lib folder in my NuGet package - my portable library can be used with .NET 4.5, ASP.NET Core 5.0, Windows 8, Windows Phone 8.1 and Windows Phone Silverlight 8 projects.
I tried to look up the framework profiles and their corresponding NuGet abbreviations, but I couldn't find them in the official documentation. Stephen Cleary gathered up profiles a while ago, but his list does not contain the profile for ASP.NET Core 5.0.
My actual question is: how should I structure the lib folder of my NuGet package? What is the profile name for portable libraries that target the framework versions mentioned above? And if I get that very profile name, is the assembly properly referenced in a non-portable library project (e.g. .NET 4.5 or WinRT)? Or should I make subfolders for the different framework version and copy the exact same assembly in all of them (which would largely increase the size of the package)? I habe seen some packages (like xunit.assert) doing it this way in NuGet Package Explorer.
The actual folder name that one has to use in this case is the following one:
portable-net45+wp80+win8+wpa81+dnxcore50

Solr Suggester component for autocompletion

This JIRA issue and this wiki page imply that there is an up-and-coming component called org.apache.solr.spelling.suggest.Suggester for doing improved auto-complete with Solr. But I'm having trouble trying to find a release that actually has this code.
The wiki says that Solr 3.x and 4.x have include it; is that insider-speak for Solr 1.3 and 1.4 respectively? I'm using 1.4.1 (via Maven), and I see no such component.
Pulling the source from here, I find it in src/java/org/apache/solr/spelling/suggest/Suggester.java. But it fails to build with:
[javac] Compiling 8 source files to /Users/user/Downloads/apache-solr-4.0-2011-02-22_08-06-33/apache-solr-4.0-2011-02-22_08-06-33/contrib/analysis-extras/build/classes
BUILD FAILED
/Users/user/Downloads/apache-solr-4.0-2011-02-22_08-06-33/apache-solr-4.0-2011-02-22_08-06-33/common-build.xml:275: /Users/user/Downloads/apache-solr-4.0-2011-02-22_08-06-33/apache-solr-4.0-2011-02-22_08-06-33/contrib/analysis-extras/lib does not exist.
Is there a way to get a reasonably stable Solr artifact with the Suggester included, preferably via Maven?
Solr 3.x and 4.x are not 1.3 and 1.4.
1.3 and 1.4 are stable releases. 3.x and 4.x are yet unreleased. Versioning scheme changed due to Solr merging with Lucene.
If you need a 4.x build I recommend getting one from the build server.
Also note there are several ways to implement autocomplete with 1.4.1, see Simple Solr schema problem for autocomplete