I am searching for an on-premise solution where I can call my application settings for my .NET Core apps from an external service like the Amazon.Extensions.Configuration.SystemsManager provides.
With this solution I want to share secrets/settings across apps and environments.
Related
We have a big ASP.NET Framework application hosted in IIS and we are considering a progressive migration to ASP.NET Core using YARP, as explained here: https://devblogs.microsoft.com/dotnet/incremental-asp-net-to-asp-net-core-migration/
The basic idea is to deploy a ASP.NET Core app that will proxy all the requests to the old application, and then move the code progressively from the legacy app to the proxy, until the legacy app is empty and can be removed.
We are wondering about the hosting of the ASP.NET Core proxy app. In priciple there is no limitation, it could be deployed in IIS alongside with the legacy app or be deployed with Docker/Kubernetes. However, we don't know if that second option will cause a performance penalty or any other kind of problem. So before doing a POC, we'd like to ask if somebody has experience with this problem and some advice about it.
I am currently attempting to take an application that I have already created as a .Net CORE Application and connect it to Sharepoint Online in the form of a Provider Hosted Sharepoint Add In.
It seems that Sharepoint add ins can only recognise .Net Framework web applications which would result in having to port the .Net CORE application to a .Net Application.
I am seeking the easiest and cleanest way to proceed with this.
Is there a way that I can create a Provider Hosted app using .Net core or should I port the .NET Core application to a .Net Framework web application?
If so, how would you go about doing this?
Even we were trying to achieve the same thing. But we ended up in .net framework. To be on the safer side, you can create a provider hosted app using visual studio, which gives better connectivity to the Sharepoint App.
.Net core to .Net framework conversion would be so simple, since the framework holds most of the libraries and functionalities when compared to .Net core. You can just copy paste the code from your.net core and you can do modifications to fit in the framework.
Otherwise, you can use oauth tokens by using SharePoint Rest API's. If you have already built the provider hosted app and installed it in your site collection, you can just use the existing client id, client secret to get the access token like this. So that you can perform everything using your existing .Net core app.
So I am playing around with Service Fabric for rolling out a system to the cloud, and so far I have most of the stateless services ported over and running well using ASP.NET Core.
I have another set of services that need to be stateful, and I would like to leverage .NET Core for those services as well. For those I will need to run a custom TCP protocol, not HTTP/WebAPI/WCF.
So the question is; is this possible? The templates only have a ASP.NET Core stateless service template. Can I build something like a .NET Core console application to run as a "Reliable Service"? If so, is there any documentation on how to do this?
Yes, it's possible.
You can create the .NET 4.5.1 stateful service via the template, and then port that project to .NET Core - we've done this and it works just fine.
There doesn't appear to be any official documentation on this process.
I'm playing with Azure asp.net development. I use Visual Studio 2010, with Azure SDK and I'm a newbie to Azure cloud.
I created several apps and deployed them to my testing Azure Web Site. Everything works fine - ASP.NET Web Page, ASP.NET MVC3, even simple GridView binding to an Azure SQL database, which I created earlier and that I manage with Microsoft SQL Management Studio, using ADO.NET. It's really simple.
Now, I learned from some tutorials, that I need to use a Windows Azure Cloud Service Project to make sure that my application will work. But it works without this project, too. So what exactly do I need such a project in my solution for?
There are actually three different ways you could have gotten your ASP.NET app over to the cloud, and the confusion comes because you are seeing elements of two of those options.
A Windows Azure Web Site is just a single ASP.NET application running in Microsoft's data centers (versus on premises) so all of the configuration it needs is already part of the project itself (primarily the web.config), some being exposed via the Azure portal. In many ways, this is similar to web hosting providers.
A Windows Azure Cloud Service is a collection of multiple services, which could be web sites/services (Web Roles) or backend code (Worker Roles). The code for your Azure Web Site could also have been deployed exactly as is as a Web Role, but in that case it would be part of a larger application that potentially contains additional Web and Worker Roles. It's the Cloud Service project itself that provides the additional configuration of those web and worker roles (even if you have just a single role in the cloud service). The Cloud Service offering is considered Platform as a Service.
The other option, for completeness, is to create a Virtual Machine image yourself, install your ASP.NET site, and then have Windows Azure host the Virtual Machine. It's at the opposite end of the 'make it simple to deploy' spectrum, but you get a lot of control over what exactly is on the VM that you deploy. This is the Infrastructure as a Service offering from Azure.
I'm going to assume you're developing for Windows Azure Cloud Services (the foundation PaaS solution of Windows Azure). The Cloud Service project defines your application to the Windows Azure Fabric. If you don't already have one, then odds are your are running your application outside of the local Development Emulator. If you are going to deploy your solution to Windows Azure Cloud Services, you will need to create this project for your application so Windows Azure's Fabric (the secret sauce that will manage your application) knows how to manage the application.
And I'm going to assume the opposite to #BrentDaCodeMonkey - that you're developing for Azure Web Sites, and not Cloud Services - in which case you may have confused yourself with the tutorials, as I don't believe a Cloud Services Project is either necessary or advisable.
I don't know this is a right forum for my question or not?
I am new in Web Services. Today i just open VS2008 and found 3 type of SERVICE project
Window Service
WCF Service application
ASP.NET web service application
Please help me to find out the difference between these three projects?
When should we decide which type of project?
Very short explanation:
Windows service is as it states a service running on Windows OS. For example, indexing service running on Windows machine is a Windows service.
Asp.NET Web Service is a service that can only be used via http and is hosted on server.
WCF is a framework, layer or platform that enables you to create multiplatform services that can communicate with each other. WCF services supports more protocols. Can be hosted by server, application or used by other services. You can use WCF to create a web service or a windows service.
A newer and easier approach for creating lightweight web services is the stateless Web API. I suggest you download VS 2017 Community Edition, so you are not stuck with only those choices.