Building ServiceStack.Core for open-source project - servicestack

We are developing an Open-Source aPaaS product. The project is in its very early stage.
We use .NETCore, for Web Services, we want to use ServiceStack.
For now, we are using NuGet packages. But, the number of service operations have started to go up and exceed the limit of 10.
We tried to download the Servicestack .netcore source code from GitHub (both ServiceStack/tree/master and netcore branches) but it is failing to build. Following are the errors we get:
E:\user\Downloads\Ss\ServiceStack-master\src\ServiceStack.Client\error CS0006: Metadata file 'E:\user\Downloads\Ss\ServiceStack-master\src\ServiceStack.Interfaces\bin\PclDebug\ServiceStack.Interfaces.dll' could not be found
E:\user\Downloads\Ss\ServiceStack-master\src\ServiceStack\error CS0006: Metadata file 'E:\user\Downloads\Ss\ServiceStack-master\src\ServiceStack.Client\bin\Debug\netstandard1.6\ServiceStack.Client.dll' could not be found

Related

Unable to deploy SPFx webpart to sharepoint 2019 via App Catalog

I'm having some trouble deploying my .sppkg file to Sharepoint 2019. I've developed it using the SPFx framework version v1.4.1 to ensure it is compatible, and the webpart works fine when deployed in development mode against the Sharepoint environment's workbench (https://your-sharepoint-site/_layouts/workbench.aspx).
However, after uploading the webpart to the app catalog, it displays the general error message :
Error in client-side code
and is unable to deploy. In the logs for the Sharepoint environment, after uploading the package this error appears:
Caught an exception while updating the properties of SharePoint App package AppCatalog/my-webpart-app.sppkg. Error: There were errors when validating the App package: Error in the application. Stack Trace:
at Microsoft.SharePoint.Marketplace.CorporateCuratedGallery.SPCorporateCatalogEventReceiver.PromoteProperties(SPListItem listItem, Stream packageStream, Boolean addingPackage)
at Microsoft.SharePoint.Marketplace.CorporateCuratedGallery.SPCorporateCatalogEventReceiver.HandleItemAddedOrUpdated(SPListItem listItem, Boolean categoryChanged, Boolean addingPackage, Boolean isDeploying, Boolean beforeIsDeployed, Boolean beforeIsCurrentVersionDeployed)
The same package deploys fine in a Sharepoint Online environment. I don't have another 2019 environment to test in.
I'm a bit at a loss of how to debug. A test .sppkg file built from the starter SPFx project using version 1.4.1 deploys just fine, so my only thought is to slowly add functionality to the base package and deploy new versions until it breaks, but that feels a bit like madness.
Does anyone have any insight into what part of the packaging process might cause the .sppkg file to be unable to run when uploaded? Could it be permissioning issues in the environment?
Metadata of you .sppkg has errors:
There were errors when validating the App package: Error in the application.
I think, main error - you not create clean project. Create clean project, by using this info
yo #microsoft/sharepoint
Don't mistake, answer this question:
Which baseline packages do you want to target for your component(s)?
There are 2016, 2019, SharePoint Online only (latest)
If your package was created for sharepoint online - it not be added to sharepoint 2019 On Premis.
Permissions errors you will see in app catalog, and uls logs. Your error - incorrect metadata of package.
Sharepoint starter kit has this info
Starter Kit Version 1 includes a comprenshive strategy for only SharePoint Online, as well as a single SPFx solution that encapsulates all webparts and extensions into a single package. Version 1 may be accessed via the v1 branch for legacy purposes and will not be maintained beyond April 2020. link
so, don't modify it:) it's alredy legacy.
For developer own packages on premises - you can create single server farm. If you work in sharepoint online - you can use Office 356 developer programm

How to build an external class library for use with a solution in a CI Pipeline in Azure DevOps?

I've requested to my Team Lead that we start integrating a CI/CD pipeline into most, if not all, of our projects. Our newest project relies heavily on our own, external class library that is referenced in the solution ; it is under "Dependencies" as a project reference.
The project runs fine when I build it in my machine using Visual Studio 2019, and before we needed to integrate an external library, it would build and release fine using our Azure DevOps pipelines.
However, with the addition of an external class library, when I try to run a build through Azure DevOps, I get the following error:
The project file ....csproj was not found.
I fully understand why it can't find it - because I need to pull in the external class library and build that first! There doesn't seem to be a lot of online material (not that I could find anyway!) that describes solutions to this other than "use nuget" ; unfortunately, it is a requirement from my Team Lead that this is not a route we go down - which has lead to a long couple of days!
With this in mind, I can't find another way to do this in Azure DevOps. I have looked into some sort of PowerShell command but to no avail thus far.
Has anyone run into this issue before with external class libraries in DevOps and can give me advice on the best way to approach it?
Generally speaking in 99,99% cases keeping a direct reference to the project is not a good idea. You can end up with really unmaintainable CI/CD logic and/or with dll versions mismatches during deployments. Actually I am an Architect in the project where I tried to fix that issue by migrating all dependencies to the NuGet server.
Azure Artifacts
You mentioned, that you are using Azure DevOps as main CI/CD tool, so this is a great opportunity to introduce Azure Artifacts as internal nuget server which is a part of Azure DevOps. For the first 2 GB it is free, here you have pricing details.
Alternatives
If for some reason you cant use Azure Artifacts, I recommend some alernatives:
MyGet
ProGet
Own nuget server
More information about alternatives you can find in this article.

.NET Core Runtime Package Store on Linux

I created a console application and added Newtonsoft.json as reference for test.
After following the steps, I published the application (netcoreapp2.0) to ubuntu.16.04-x64 version and deployed it to a Ubuntu(16.04) machine, when I run the console application, it always shows below error even the package exists in /usr/local/share/dotnet/store
An assembly specified in the application dependencies manifest (RuntimePackageConsole.deps.json) was not found:
package: 'Newtonsoft.Json', version: '11.0.1'
path: 'lib/netstandard2.0/Newtonsoft.Json.dll'
This assembly was expected to be in the local runtime store as the application was published using the following target manifest files: artifact.xml
After I changed the path of Newtonsoft.Json.dll in dependency json file to absolute path, then it works.
Anybody had the same issue on Linux? Or how can I find out the reason, why can't application load the package by relative path in dependency json file?
It looks like you are targeting a manifest when you publish your code.
Starting with .NET Core 2.0, it's possible to package and deploy apps against a known set of packages that exist in the target environment. The benefits are faster deployments, lower disk space use, and improved startup performance in some cases.
This feature is implemented as a runtime package store, which is a directory on disk where packages are stored (typically at /usr/local/share/dotnet/store on macOS/Linux and C:/Program Files/dotnet/store on Windows). Under this directory, there are subdirectories for architectures and target frameworks. The file layout is similar to the way that NuGet assets are laid out on disk:
A target manifest file lists the packages in the runtime package store. Developers can target this manifest when publishing their app. The target manifest is typically provided by the owner of the targeted production environment.
https://learn.microsoft.com/en-us/dotnet/core/deploying/runtime-store
So you may want to take a look at your environment and ensure that your package stores do in fact have the required libraries, or that you publish without a manifest.

Azure Function Structure

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.

Servicestack - run built-in clients on the .net client profile framework

Is it possible to run servicestack's built-in clients on the .net client profile framework?
When i change the target framework property in the project settings to ".Net Framework Client Profile" and try to compile i get the following message: the namespace ServiceClient does not exist in the namespace servicestack.
We use servicestack services to send exception reports. We use the JsonServiceClient and feel really comfortable with it. We could change the target framework - but then we have to check all installations for the availability of the full .net framework.
Any idea how to solve this?
Thanks.
From the package contents of the latest ServiceStack.Common package there seems to be no -client version included (See Common Framework and Profile Targeting Examples under NuGet - Creating and Publishing a Package).
You should either change the target framework the full profile or pull the code from ServiceStack's GitHub Repo and try to build it for client profile yourself. The downside of this is that you will loose Nuget's awesome update features...
You could off course file an issue at GitHub for the guys maintaining ServiceStack to add a client profile version of the framework, but I guess that there's a good reason for why it's not there already.

Resources