Just noticed that in my list of Nuget packages, that "NLog.Config" is marked as deprecated:
Is it safe to simply delete the package?
This particular application is for Google Calendar API usage.
I should have looked more closely at my code. I removed the package and now my tool won't compile. I have code like:
Imports NLog
Private m_logger As NLog.Logger = LogManager.GetCurrentClassLogger()
And 10 instances of calls like:
m_logger.Error(ex, "RESULT_FAILED_OAUTH")
How to resolve now that NLog is deprecated?
NLog.config-nuget-package is safe to remove, and one is encouraged to remove it. It became obsolete when Microsoft introduced <packagereference>-syntax.
Now the NLog.config-nuget-package actually causes issues because it can reset the NLog.config-file on application-publish (Same story can also seen on the nuget-package-page)
Just replace it with NLog-nuget-package, if you don't have it installed already.
Related
These 2 libraries seem to serve a similar purpose: to securely store and control the access to tokens, passwords, API keys, and other secrets.
I have been using Microsoft.Azure.KeyVault with some success, not for configuration secrets, but for keys.
Not until recently did I discover Azure.Security.KeyVault.Secrets.
In release notes I found this:
Updated Microsoft.Azure.KeyVault with its successor Azure.Security.KeyVault.Secrets to resolve key vault references.
What are the distinguishing attributes of the 2 libraries, and how to determine the appropriate choice.
Should I interpret the release note to imply Microsoft.Azure.KeyVault is obsolete or will be deprecated?
What are the distinguishing attributes of the 2 libraries, and how to
determine the appropriate choice.
The package Azure.Security.KeyVault.Secrets is the most up-to-date version of the Key Vault client library, which is recommended to use for any new project. For main differences from the legacy one, see this
Major changes from Microsoft.Azure.KeyVault. For usage, please refer to this doc.
The other package Microsoft.Azure.KeyVault is now a legacy one, if you have some old projects which use it, you can keep using it. For usage, please refer to this doc.
You can refer to this article for more details why these new client libraries(including Azure.Security.KeyVault.Secrets) are published.
Should I interpret the release note to imply Microsoft.Azure.KeyVault
is obsolete or will be deprecated?
It is hard to say if the old one will be deprecated in the future. At least from the
Release History, it says the new one is not a direct replacement for Microsoft.Azure.KeyVault(like other azure services, for example, azure storage service published a new version package recently, but not officially pronounced the old one is deprecated). But we suggest you should use the new one in any new create project like it says in the doc, a screenshot of this:
Hope it helps.
I'm using VS 2017 RC. I've been told to use it to get the proper experience with .net core going forward, so that is where I am at.
I am trying to add the nuget package WindowsAzure.Storage into my ASP.NET Core application. I keep getting a message stating that one of the dependencies is not compatible.
From reading up in some various forums, the problem appears to be the OData dependency. Additional reading has shown that if this were running under VS 2015, I could use an imports statement in the project.json file to get this to work.
Question: what is the equivalent statement that I can add an imports statement into the vs2017rc proj file?
what is the equivalent statement that I can add an imports statement into the vs2017rc proj file?
PackageTargetFallback is a new design for Imports and is used in csproj, if you’d like to know detailed information, please read this documentation.
We have an Azure function which references an external assembly via a private Nuget feed.
The problem we're having is that we have two different versions of Microsoft.Azure.WebJobs.dll - one which is a dependency of our nuget package and another which I'm assuming is being provided by the runtime.
error CS1503: Argument 2: cannot convert from 'Microsoft.Azure.WebJobs.ICollector<Microsoft.WindowsAzure.Storage.Table.ITableEntity> [D:\Program Files (x86)\SiteExtensions\Functions\1.0.10635\bin\Microsoft.Azure.WebJobs.dll]' to 'Microsoft.Azure.WebJobs.ICollector<Microsoft.WindowsAzure.Storage.Table.ITableEntity>
I found this question which says that binding redirects are not supported:
Azure Functions binding redirect
We could try to remove our dependency on that library, or we could match the version used by Azure Functions, but I think we're going to have the same problem with using Microsoft.WindowsAzure.Storage anyway.
Please advise!
You are correct that binding redirects are not supported. The runtime has its own dependencies on the WebJobs SDK and Storage libraries so objects passed into your functions will be from those versions. I recommend removing your dependencies on other versions and snapping to ours. Note that for these libraries, you don't have to add your own package reference, you can reference ours in your function code via:
#r "WindowsAzure.Storage"
You don't need to add explicit #r references for WebJobs SDK types (e.g. ICollector<T>) - the runtime adds that assembly implicitly. Of course this only applies for function code we're compiling for you, not code coming from your external packages.
In the future we might improve things in this area, but for now you'll be swimming up stream if you try to use conflicting versions.
Are there any plans for the ServiceStack packages to start using the SemVer standard? We just had an unfortunate circumstance where we were broken by the interface breaking changes introduced in 4.0.44 from 4.0.43 around OrmLite.
We are a sizable commercial customer and have a custom implementation of a OrmLiteDialectProvider for one of our DBMSs, it all seemed good upon the initial upgrade in our web application, however as part of testing the changes around type converting broke our system. This wasn't initially evident as part of the upgrade because our custom implementation is in a NuGet package which overrides OrmLiteDialectProvider.ConvertDbValue on version 4.0.38 which is now gone. There were no binding issues because it is only a minor version difference.
NuGet adopted SemVer back in version 1.6.
Having the SemVer standard would make it a lot easier for us to know when interface breaking changes have been made, without having to dig through the Release Notes page.
NOTE: The release also didn't indicate that the old method had been removed and upgrading would break any custom implementations.
UPDATE FROM RESPONSE
Anyway, fair enough answer. I can appreciate it would be difficult to track each package individually. In our case we wrote a custom dialect provider as we have a legacy DBMS that wasn't supported and this appeared to be the way we were supposed to add the support. We wanted to use ORMLite because we use the rest of ServiceStack and it's a fantastic product.
The new way to support the types is a great improvement and actually made our implementation easier.
We actually ran into this issue because we do always keep our ServiceStack packages inline and were upgrading the ASP portion for some fixes to the WSDL generation and this came along as part of our upgrade.
ServiceStack adopts a single rolling version for all NuGet packages which all share the same Version number. Of all ServiceStack's 60 NuGet packages it's likely there's a breaking change to at least one of the packages so semver would be useless, you should also never mix and match different versions of ServiceStack together - when you upgrade, upgrade all packages to reference the same package versions. We do aim to keep user-facing breaking changes to a minimum, by looking to deprecate old API's first, maintain parallel API versions for a while then list the new API's release notes.
IOrmLiteDialectProvider is not a user-facing interface
However IOrmLiteDialectProvider is not considered a user-facing interface since it should be extremely rare that anyone implements their own custom provider. It's also the interface for specialization for all RDBMS's and often changes with every release to support new features, internal refactoring, optimizations, etc. E.g. implementing Type Converters was a major internal refactor that required changes to IOrmLiteDialectProvider but did not affect OrmLite's external user-facing API, later releases includes optimizations requiring further changes, again this doesn't affect OrmLite's external user-facing API.
SemVer won't help here, every ServiceStack version potentially has a breaking change in some of the packages and we have no intention to complicate each release by versioning each of the individual packages differently. The issue you're having is depending on an unstable Interface that's not intended for customization. It's not treated as a user-facing API so we don't try to maintain compatibility with existing versions or publish breaking changes which happens nearly every time we add features / optimizations to OrmLite. You should instead check the commit history of
IOrmLiteDialectProvider for any changes to this interface.
I have been trying to get Moq (or rather Castle.Core) to create proxies for my internal types.
The following (when added to my project under test), allows things to work:
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]
However this (more secure version) does not:
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2, PublicKey=002400000480000094000000060200000024000052534131000400000100010077f5e87030dadccce6902c6adab7a987bd69cb5819991531f560785eacfc89b6fcddf6bb2a00743a7194e454c0273447fc6eec36474ba8e5a3823147d214298e4f9a631b1afee1a51ffeae4672d498f14b000e3d321453cdd8ac064de7e1cf4d222b7e81f54d4fd46725370d702a05b48738cc29d09228f1aa722ae1a9ca02fb")]
Note: the public key here differs to that documented here, I re-checked the public key of the Castle.Core.dll that ships with the current Nuget version of Moq.
Do I still have the wrong key?
[EDIT]
I have noticed the full Moq download from the official site (rather than Nuget) contains a NET40-RequiresCastle folder with a smaller dll, which implies that the Castle.Core code has been included in the default Moq.dll I guess.
I was looking at the Castle.Core.dll they provide for Silverlight and assuming they'd have used the same version throughout?
I know this is old, but for anyone who stumbles across this, I was having a versioning issue with Pex and Moq at one point, and wound up finding the most direct and useful approach to be the Strong Name Tool. That is, I found opened a Visual Studio command prompt and used "sn -Tp ThirdPartyAssembly.dll" to query it for the key directly. This proved a lot more efficient than perusing the internet looking for different, documented public keys to try out.