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.
Related
I have a solution in Visual Studio Team Services that has 2 Web Applications (specifically one project for WebAPI services and another for the actual site using MVC).
I'm trying to set up continuous delivery to Azure but all the information that I can find seems to assume that you only have a single Web Application within your solution (which seems a little unrealistic for all but the simplest of projects!).
The out of box continuous delivery process seems to just pick and deploy the first Web Application it finds (which isn't necessarily the same project each time!)
I've tried specifying the Deployment Settings file, but that seems to affect the destination rather than the project being deployed since again, it seems to just "pick" a project to deploy, and each time it deploys every single compiled assembly plus all dependencies rather than just the binaries and dependencies of the project actually being deployed, which can cause issues with MVC finding duplicate controller matches for a given name (this can of course be fixed by specifying the namespace of the controllers within the route configuration, but that seems less than ideal, and still doesn't fix the entire problem).
Ideally I'd like to find a way to deploy both projects with a single build, but as a temporary solution I'd be happy with 2 builds that are both triggered by a check-in of the single solution, that each reliably deploy 1 of the 2 Web Applications.
Does anyone know if this is possible? I guess I could write my own custom build template, but I'm hoping there is an easier answer (not least because I can't imagine that this isn't a problem being faced by other people!)
I did find this question TFSPreview.com and Azure continuous deployment for multiple solutions in TFS but since that's quite old and is specifically talking about AzureWebRoleProjects rather than Web Applications being deployed to the newer Azure Websites feature, I'm hoping that there is a more positive answer?
This is possible with multiple build configurations. In addition to Debug and Release you could specify two more, one for each app.
You can find these in Visual Studio at Build -> Configuration Manager. And then in the configurations specify only one of them to be built. Then running MSBuild with that configuration will output only one WebDeploy package.
I have an MVC Web App that I am trying to get set up with continuous integration on Azure and Visual Studio Online. Basically, the solution has 4 projects within, 3 of which go to supporting the 1 Web App. The problem is, when I set up continuous deployment on Azure, it builds the entire solution and doesn't know which project I want for the root URL.
When I download the drop folder that is produced by the compilation it looks like this.
drop/lots of dlls including the dll of my web app.
drop/_PublishedWebsites
drop/_PublishedWebsites/MyWebApp (including its bin, content, fonts etc)
drop/_PublishedWebsites/MyWebApp_Package
and some other folders as well.
How can I configure the continuous deployment to put my Web App at the root of the website??
Thanks
Looks like the dumb solution is to rename your "main" project to be the alphabetically first project in the solution. Microsoft suggests this, or having only one project per solution. Either way, this is the most reliable and simple way to get the desired effect.
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.
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.
We are investigating using CruiseControl.NET as both a Continues Integration build provider, as well as automating the first part of our deployment process.
Has anyone modified CruiseControl.NET's dashboard to add custom login and user roles (IE, Separate out access to forcing a build to only certain individuals on a per project basis?
The dashboard is a .NET App, but I believe it uses the nVelocity view engine instead of web forms, which I don't have experience with.
Can you mix nVelocity and Webforms,or do I need to spend a day learning something new =)
#Keith:
We are leveraging CC.NET to both run a CI build, as well as being able to use the Force Build feature to do a Build + Deploy. That is why we want hands off the dashboard.
I found this morning that I was able to place CCNET in a virtual directory within another web app, This allowed me to setup Forms Authentication, and let the root app manage that. Problem solved.
Why do you need to? Do you really need to limit users in the way with an integration server. I think that's why CC.Net doesn't have that sort of support built in.
You can always see who forced a build, and control it that way.
I find that continuous integration works best with regular builds and regular unit test runs (our rather large C# app + test run takes 25 mins and checks hourly), so for me forcing a build is rarely an issue.
If you want some users to have some kind of report-only access you could limit them so that they can't access the CC.Net web application at all.
All the results (MSBuild, NCover, NUnit, FxCop, etc) are in XML, so you can build relativity simple report pages out of XSLT.