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.
Related
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.
I'm trying to wrap my head around how we're supposed to build Azure functions.
I love the idea of building serverless, compact, single-function apps that respond to events.
Here are the problems I'm running into:
I have nice class libraries built in .NET Standard 2 that handle all my "backend needs" namely handling CRUD ops with Cosmos Db, Azure Table Storage, Azure SQL, Redis, Azure Storage. No matter what I did, I couldn't integrate these class libraries into an Azure Functions project. More details below.
Also, getting dependency injection in Azure Functions project has proven to be quite a task -- especially with my class libraries mentioned above.
At this point, the only option I'm seeing is to "copy and paste" code into a new Azure Functions project and use it without any DI.
This seems to go against "best practices". So what's the solution other than either to create monolithic code or wait till Azure Functions support .NET Core and DI.
I thought I could use my .NET Standard class libraries from a regular Azure Functions project targeting .NET Framework. After all, the idea of .NET Standard is to "standardize" things. I opened a couple of posts here on SO. I'm providing the links so that you can see the issues I've run into:
Using .NET Core 2.0 Libraries in WebJob Targeting .NET Framework 4.7
No parameterless constructor error in WebJobs with .NET Core and Ninject
P.S. My previous posts are referring to WebJobs. That was plan B approach because WebJobs seem half a step ahead of Azure Functions when it comes to supporting things like .NET Core and DI. Ultimately, I'd like to build a few Azure Functions that can use my class libraries built in .NET Standard 2.
Also, my previous posts mention that my class libraries target .NET Core 2.0. Since then I converted them to .NET Standard 2 which didn't really take much at all. I did this so that I truly conform to .NET Standard 2.
One issue is that Visual Studio has an outdated version of the Functions Core tools. Until this is resolved, you can work around in the following way:
Install the latest via npm by running npm install -g azure-functions-core-tools
In your Function App in VS, go to the Properties
Go to Debug, and click New... under Profile
Name the new Profile something like FunctionsNpm
Set the executable to (replace [YourUserName]): C:\Users\[YourUserName]\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.exe
Set the arguments to host start
Set the working directory to $(TargetDir)
In toolbar, look for the green triangle icon to change your current Profile to the one you just created:
Now when you run from VS, you'll be using the npm tools instead of the older one that come with the VS package.
.NET Standard 2 support is on its way, see this github issue.
I'm getting the following error compiling a program using a 3rd party library:
Error:(xx) No resource identifier found for attribute 'tint' in package 'com.example.mycompany.myapp'
The line xx is inside the xml layout that includes a custom component defined in the library.
cntrlco:tint="42"
The xml namespace documentation says I need the following:
xmlns:cntrlco="http://schemas.android.com/apk/res-auto"
Here's my best guess as to the problem, but if you think otherwise please let me know, this is a guess.
I suspect I don't have the library installed completely. The reason is that the library instructions want the library installed from maven. I'm not up on this technique, but it appears to be a web based auto install that automates dependency installs while performing the primary install. Nice idea, but I can't install using the web (long story), so I included the .aar file locally.
From my research, installing .aar files locally won't look at its dependencies. If this is true and the "tint" property is defined in a dependency, then this would explain the error I'm seeing.
Is there a way to follow the error chain in more detail so I can verify my theory? Along the way, will this help me find the name of the possible missing dependencies so I can see if including them fixes the problem.
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.
Recently I am working on servicestack project. When I am trying to add open ServiceStack.ServiceInterface in project it is showing below error.
PFB image for code.
As suggested in error, when i am trying add open ServiceStack.Interfaces then it is showing dll is not present.
please tell me why it is showing error?
What is different of this two DLL?
ServiceStack.ServiceInterfaces contains interfaces used by the ServiceStack webstack while ServiceStack.Interfaces is used by the various other ServiceStack projects (like OrmLite) as well.
ServiceStack.ServiceInterfaces depends on ServiceStack.Interfaces, which means you have to install it as well (it is a seperate nuget package)