I have a console application project which is a workflow service self hosted using WorkflowServiceHost. It contains a flowchart workflow definition (xaml) and some custom activities in cs files. This application connects (via a service reference) to a WCF data service hosted as .svc. I have an aspnet web app that interacts with the workflow service via a service ref. It's all working fine.
I'd like to convert the workflow service console app to instead be hosted on IIS (I'm developing using IIS5 and the live environment is IIS6) but am unsure how to go about it. I tried creating a WCF WorkflowService Application project and copying my xaml (changing to xamlx - not sure if I needed to do that or not) and cs files in, and created a service reference to my WCF data service but when I tried to browse the xamlx I got an error "Cannot create unknown type x" x being a type that it should be able to "see" via the service reference it has.
What are my options for hosting - do I have to use WorkflowServiceApplication or can I host using .svc? Can someone point to a tutorial or talk me through what I need to do? Also I would like to have the workflow definition in a class library project if possible, thus separating it from its host. Not critical though.
A XAML and XAMLX file are almost the same but not quite. The XAML file results in a class being generated to wrap the XAML and you work with that type as if it is a normal class. A XAMLX file is not compiled and parsed at runtime. The root element is also different for the two and the XAMLX has no x:Class attribute because it isn't compiled.
The easiest way is to just create a XAMLX file and copy the activities from the XAML file into the XAMLX file.
Related
I have succedeed in deploying a simple client web part on a SharePoint 2016 site with the following steps (following many guides, including https://www.voitanos.io/blog/definitive-guide-sharepoint-framework-sharepoint-server-2016/):
I configured the required Service applications (subscription and app management) and managed the blocked file types.
I created an App Catalog site for my Web Application.
I wrote two urls in "Central Administration -> Apps -> Configure App URLs" (it seems that it doesn't matter what URLs I write, the important thing is that they are not empty or I can't add the App to my sites).
I set up my CDN by creating a Document Library and a folder. I specified this location in the write-manifest.json -> "cdnBasePath".
I uploaded the sppkg (output of gulp package-solution --ship) to the App Catalog and it got distributed succesfully.
I went to the root web of the site collection I was working on and added the App.
I created a web part page with an empty web part zone and.
I succesfully added the client web part that was in the default "Other" group, and it rendered fine in the page.
Until here everything is fine. There was some tweaking to do with yeoman, gulp and node versions, but it works.
The problem is that if I add the app to the site root web, the web part is not available to the other webs, since from what I read, if I add an app that way the scope is only that web. In order to make the web part available on other webs, I would have to go to every web and add the app there. This could be fine if I had 2 or 3 webs, but what if I have 1000 webs?
I also read that if you add the app to the App Catalog Site, the scope should be "tenant", and you can then choose where to distribute the app so that it's added for all webs from this page:
https://i.stack.imgur.com/MAX8K.png
If I add the target site here, and the press "OK", an exception occurs:
Exception in page: https://i.stack.imgur.com/S8cl1.png
Exception in log: https://i.stack.imgur.com/K2GMB.png
I tried debuggingg the Microsoft.SharePoint.ApplicationPages.AppInvPage.SetControlStateUsingAppInstanceId method with dotpeek and I think I was able to identify the problem with the AppManifest object, that seems to have some null fields that on which gets called a "ToString", but wasn't able to pinpoint the exact problem yet.
So I thought I could maybe write some PowerShell script to add the App to all subsites, but it seems the method require some parameters that somehow don't seem right. For example, Install-SPApp requires a SPApp object that is obtained with Import-SPAppPackage. Even if I manage to launch the command with the .sppkg file stream, when you launch Install-SPApp an exception occurs: "Install-SPApp : Value cannot be null.".
Honestly I'm running out of ideas.
TL;DR: Has anyone had issues with SharePoint 2016 and globally deployed client web parts? Is it possible to automatically add the app containing one or more client web parts to all subsite on SharePoint 2016?
I am new to Azure WebJobs. For a mobile app we need some WebJobs that can run scheduled. My question is about the "Projects-Architecture" when it comes to WebJobs.
As far as i know, a new project is created for every WebJob. I am doing this by righclicking the main project -> add new azure webjob project.
But how are these projects "combined". There should be some reference to the parent project that i cannot find. I need to access the entities from the main project inside the WebJob. How should this be done?
Furthermore i am not sure wheter to implement Logic+Data access directly inside the WebJob or let the WebJob instead call another Controller to handle this?
Documentation on this is horrible, every help would be great.
They are not really "combined". There is a reference in the Web App (the webjobs-list.json) in properties that tells VS to publish the webjob when you publish the web app. If you need to access entity models in the webjob, then you need to add a reference to your other projects just like you would in any other project (add the project reference and then add a using statement in the webjob). The reference will get compiled into the webjob.
May I ask what are you trying to achieve via the web job? this would help in identifying why the need for accessing the models of your MVC app.
One suggestion would be to push the object from the MVC app to an azure queue and then access it via your job. Set it up in a way to identify new messages in a queue. (trigger). - not sure if this helps cause I am not sure how quick the web job is run and what are the other constraints you are working with.
When you add a new or existing WebJob Project to your solution, Visual Studio will take care of this for you. It is not something new, as if you are adding a console/windows service project to your web/MVC application.
If you need these projects to communicate, you till need to add references to your other projects just like you would in any other project which will in turn get compiled.
If you need to learn more and check some examples, this tutorial https://azure.microsoft.com/en-us/documentation/articles/websites-dotnet-webjobs-sdk-get-started/ shows how to write code for a simple multi-tier ASP.NET MVC 5 application that uses the WebJobs SDK. Maybe that can give you some information on how to architect the application.
I am building a SharePoint 2013 provider-hosted app using the high-trust model. This allows a customer to deploy the .app to their App Catalog and make it available to all SharePoint Sites. The provider-hosted portion of the app runs in an IIS box (cluster) which the customer also deploys (on-premise) with setup instructions and automated tools.
The .app file structure includes the application manifest - which specifies the precise endpoint where the provider-hosted portion resides, and also specifies whitelisted endpoints which the add-in can call. These are all specified by entering in URLs, hostnames, and port numbers into edit fields in Visual Studio in the 'Deploy App' form just before the .app file is built and digitally signed.
This seems to work just fine for a single app built by IT folks internally, if the org is small enough... but I really want to be able to distribute this solution to more than one customer. In order to do so, I would have to ask the customer for their respective endpoints, enter them into my build tools, and rebuild the .app for them. This just doesn't seem right... no customer wants to talk to the developer first and have a custom-built app. And why should they? No code is changing...
Upon investigation into the .app file format, it turns out it is really just a simple .zip file - and inside (voila!) there is the app manifest! Unfortunately, if you edit the app manifest and re-zip the file, the digital signature is broken, and the .app no longer works. (grrrr...)
What I want to do is simply reconfigure the app manifest to match the environment where it is deployed. This can happen programmatically during setup/installation time, or perhaps even just prior to download, but cannot be a process that involves developers typing into visual studio and pressing Rebuild. That simply won't scale.
Is there a tool that exists that can help with this problem? If not, does anyone have experience with the signing of .app files programmatically? I'm open to skinning this cat in any way possible.
This is a wild idea and not maybe even possible.
Create web ui, where clients enter their endpoints.
Have internal process that invokes MSBUILD/TFS to package app with endpoint
change app manifest with pre-build powershell
Then provide app via email or download?
http://www.sharepointconfig.com/2013/10/building-sharepoint-2013-apps-with-tfs-2013/
This is more of a workaround than a true answer - but would work:
For on-premise deployments of high-trust SharePoint 2013 apps - build the application with "known endpoints" - essentially hard-coded endpoints that can be deployed locally. Then instruct the customer to redirect those endpoints using DNS records or hosts file entries. In addition, the client would need to generate a local wildcard certificate signed by their own trusted root in order to satisfy the SharePoint 2013 app model requirements for appdomain and server-to-server communication.
This is by no means ideal, but for certain environments it might be the most practical approach. This also allows scaling for the IIS WebApp to occur at the customer-site, where it realistically belongs for a high-trust app.
This approach avoids the need to automate build tools and also avoids building a separate instance for every customer - both of which are somewhat undesirable. It might, for those reasons, be slightly less costly - but it also pushes some responsibility to the customer. Namely - hard-coding a DNS entry locally for machines in the topology.
I have a web application project in VS2012 which I'm publishing using a "Web Deploy Package". I want this package to include app-pool settings, specifically creating an IIS app-pool and assigning the newly created application to it.
I'm familiar with the option "Include application pool settings used by this Web project" available when the project is configured to use an IIS instance (not IIS Express), but IIS configuration is not part of the project file, and thus not source controlled. What happens when somebody builds a deployment package on a machine that hasn't had IIS meticulously configured? Not ideal.
How else then, can I go about getting AppPool settings into my web deploy package? I understand that the appPoolConfig provider is IIS7+ only, I'm fine with that limitation. I've banged my head against this issue in the past and never found a solution. 18 months later, we've got a new VisualStudio version, and a new web-publishing-pipeline, are there new options to address this? Or maybe something I missed when I first tackled this problem?
Edit
OK, I'm seeing the following as options:
Configure my project to sync settings from an IIS instance. As mentioned, I'm not a fan of this given that it puts settings outside of the project, meaning the environment has to be meticulously configured to build + publish. Plus it drags along other IIS settings I don't want included.
Inject something into the web-publishing-pipeline (WPP) to modify the archive.xml. I've toyed with this in the past and had limited success. One problem is the pipeline isn't exactly co-operative with working directly on the archive.xml file, another problem is some of the more cryptic attributes involved, like MSDeploy.MSDeployProviderOptions which appears to have some Base64 encoded binary? No idea what to put in there.
Find an existing "provider" that can do what I want. I might be out of luck here, the appPoolConfig provider only seems to want to read / write IIS, not, say, an XML file of settings. Does anybody know otherwise?
Write my own "provider" to produce manifest output entries. I'm not sure, is it possible to write a custom provider that writes to a manifest using the name of an existing provider? As in, MyCustomPoolProvider writes appPoolConfig sections into a manifest? This sounds like a potentially painful exercise that may or may not work. Would I still need to figure out the encoding of whatever is going into MSDeploy.MSDeployProviderOptions?
I get the feeling that the fundamental obstacle with Web Deploy for what I'm trying to accomplish, is how strictly it leans on "providers". The pre-existing providers are largely designed for IIS synchronisation, not primary development and publication. It so happens that some of these providers can be relatively easily hooked into via MSBuild, but the majority insist on pulling data from IIS, and that's that.
You are correct in your understanding of the appPoolConfig provider, in that it can only sync between App Pools and can't be provided with the configuration directly. What you could potentially do is keep a copy of the appPool in question in package form (ie. msdeploy -verb:sync -source:appPoolConfig=PoolName -dest:package=apppool.zip) and attempt to hijack the pipeline so that the MSDeploy call adds the application content into the package, leaving the existing content there.
Alternatively, you could always keep the packages separate and deploy them with different calls to MSDeploy.
FYI, MSDeploy.MSDeployProviderOptions is simply an encoded version of the parameters supplied to the provider when it was packaged. For example, -source:dirPath=c:\,ignoreErrors=0x10293847 -dest:package=package.zip would package the ignoreErrors value.
I created a wsp solution that which create 2 custom workflow actions. I want to deploy it to my 2 servers farm which have an application server and a webfront end server. SPF Web application is not activated on the app server.
My visual studio solution goes like this:
-One project which create the dll, where actions code is.
-One project which create the wsp package, feature, etc. The package references the other project as additional assembly.
My problem is, when I deploy my wsp package with Deployment Server Type WebFrontEnd, the feature is only installed on the wfe and I can't activate it. I can't see the feature in the manage feature page (the feature is farm level). When I change the Deployment Server Type of the package to ApplicationServer, I get the following message:
"This solution must be deployed to application servers, not front-end Web servers. It cannot contain a resource that is scoped to a Web application."
I did some tests. I removed the additional assembly from my package and then I can deploy my wsp solution as ApplicationServer type (but can't use my custom actions..). Then I created a dummy dll with nothing in it, added it as additional assembly to my sharepoint package and I realised I can't deploy my wsp as ApplicationServer type again.
So, can I reference an additional assembly from my wsp solution and still deploy as ApplicationServer type??
How can I deal with this? Any idea?
I did it again, I've been looking for answers for this all day, I finally post something here and one hour later, I got myself the answer. Here it is anyway.
I deployed independently both solutions using 2 wsp packages. One simply deploys the dll into the gac (and is ApplicationServer), the other one is using it without deploying it itself (and is WebFronEndServer). Now I have to deal with making sure the first one is deployed before using the other one... Feature activation dependency should do it.
Regards.