I am looking to replace Enterprise Lib. Cache with App Fabric distributed cache engine. I am going to be honest - I have no idea where to start. I know that SharePoint 2013 is already utilizing App Fabric so I my first concern is of configuration and overall architecture:
Can I use the same engine used by the SharePoint farm or do I have to rely on my own custom instance?
Related
I am working on a solution that requires many continuously running web jobs. I don't want to package these with any of the Web Apps that are part of our product for reasons of isolation and performance.
I guess some Azure Dev Ops work is involved, but my question is do I have to create Web app with no code, like a Weather Forecast type of project in order to deploy my web jobs.
You are correct. Azure does not have any standalone resource for webjobs. You can create an empty webapp and use that to host your webjobs. Or, you can check out Azure Function app which is quite similar to web jobs as it also utilizes WebJobs SDK but have some additional features as well as constrains. Chris has explained more in details in his answer.
I would like to know what is the real benefit of using azure web job sdk in web job.
I have some business logic to be executed without any interaction with storage,service bus.It is interacting with Sharepoint and Azure Sql. I have checked question here -Basic of Azure WebJobs SDK
which says JobHostConfiguration is not required for the job.
In which cases the JobHostConfiguration and webjobs sdk will be required and why we should use that?
WebJobs 3.x targets .NET Standard 2.0. This means you can use it from a .NET Framework application or a .NET Core 2.x application, the choice is up to you. If you want to make a .NET Framework application that uses WebJobs, then follow the same guide but with a .NET Framework console app as the starting point (instead of .NET Core).
If you're planning on deploying this webjob to a webapp that is running a .NET Framework application, I think it makes sense to use .NET framework for the webjob too.
You can refer here for more details on Webjobs Host.
Webjob SDK Version 2.x
The JobHostConfiguration class has a UseDevelopmentSettings method that enables development mode. The following example shows how to use development settings. To make config.IsDevelopment return true when it runs locally, set a local environment variable named AzureWebJobsEnv with the value Development.
Please let me know if this helps.
I'm looking to change deployment into DevOps (continuous delivery).
I get different technologies from Devs and Ops in the organization:
(Ops) Microsoft Deployment Toolkit
(Dev) Desired State Configuration
(Dev) Release Management for TFS
Which of these technologies work well together?
Does anybody have experience setting up continuous delivery for ASP .net MVC website with Java based backend on VMWare?
Can we keep on using TeamCity as Build Server?
Kind regards,
AllWorkNoPlay
Consider using CloudMunch for this. CloudMunch supports Microsoft stack, VMWare, and Java stacks as well.
Disclaimer: I work at CloudMunch
I am very new to SharePoint development as well as SharePoint overall, so I apologize if this question seems like a no-brainer. I'm currently working on a SharePoint 2013 app and I'm wondering if it's possible to make a call out to some URL from within the SharePoint environment. Basically, I want to do this within an event receiver after some action is done to a list, and from there I want to make a call to some web service on my server to update my system. Using the REST API to poll the SharePoint server isn't a good option for this scenario since it won't scale very well.
When dealing with SharePoint 2013 apps you can access any resource using standardized APIs. In addition to REST SharePoint is offering the JS Client Object Model (CSOM).
In order to access data from another web than the current one, your app needs the permission to interact with the entire tenant.
If you're trying to query data from another host, you have to use JSONP because of the same origin policy.
if you are building an app using the "new App Model" for wiring up Remote Event Receivers it is possible to do anything, in which your app hosting framework/environment allows you to. If you are building a Classic App (Farm Solutions) you'll have access to perform operations which are allowable from the SharePoint servers directly...typically this is a lot as GAC deployed assemblies are granted full trust.
depending on what you are trying to do and what kind of resources you app will consume. I'd consider moving the dependancies away from SharePoint and building using the new App Model versus the older farm solutions. As you sound like you are starting in SharePoint, this gives you an opportunity to learn the new ways of doing development for SharePoint.
Lastly, you might consider building a workflow. Not sure what kind of app you are building but the new workflow capabilities include actions which can make RESTful calls. Potentially making your application a "no code" solution. Again it all really depends.
we're looking to implement TFS 2010 for our teams which are split up at onshore and offshore. we've TFS Proxy in plan for the offshore team, with the TFS setup at onshore.
i know that when the clients at offshore checkout their code, it will be from the proxy whereas the webservices call will be directly on the app tier.
we will also have build machines at offshore & onshore. the onshore build machine can get the latest code version from the app tier, and that is just fine. my question is when the build machine at offshore requests a get latest, will it get the code directly from the app tier at onshore or is there a provision where the files can be got from the tfs proxy?
any help with this is going to be of much help. thanks.
MSDN: Configure Team Foundation Build Service to Use Team Foundation Server Proxy
You can configure Team Foundation Build Service to retrieve files from Team Foundation Server Proxy by modifying a registry entry on the server that is running Team Foundation Build Service. If you modify this entry, Team Foundation Build Service at the remote site can work with version control from the proxy's cache.
http://msdn.microsoft.com/en-us/library/cc716770.aspx