I have a WebAPI running on Azure WebApps developed with EF Code First.
Now I need WebJobs for some scheduling tasks which should refer to the same DB and Models.
I tried adding reference of the WebAPI project but that marks the DLL as yellow exclamation.
I'm unable to get how should I proceed. Can you please guide me a bit?
As Frederico suggests, you should split your Web API project into multiple projects.
If you isolate the Data Access Layer (EF Context + query) into a separated assembly, it will be easier for you to share the database access into several projects. Moreover you will not have to add reference to web specific dll (for example System.Web.Mvc or System.Web.Razor) into your webjob project.
Anyway you have some yellow warning because your Web API and you Azure web job don't target the same .Net framework.
Right-click on your project then select properties. you should be able to adjust the .Net Target framework.
To be able to reference a project A into project B, the project A should target a .Net framework with a version less or equals than the targeting .Net framework of the project B
I assume that your EF DbContext class and entities resides inside your Web API project. This monolithic approach brings many problems in integration scenarios like the one you shown.
My advice is to modularize your solution and move all your Data Access related classes (DbContext, entities) inside another project which will be referenced by both your Web API and WebJobs projects.
This is a common approach for improving the maintainability of the code and enforce basic software engineering principles like separation of concerns, and is obtained by dividing your application into different functional layers (a.k.a. multi-layered architecture).
If you are interested you can read more about it here: https://msdn.microsoft.com/en-us/library/ee658109.aspx?f=255&MSPPError=-2147217396
Related
I am at the point in azure manager where I have to choose for xamarin.forms: create new app(too much unnecessary content) or connect an existing app(which I think is better). I have a blank xamarin.forms project and I cannot figure out in which specific files to put necessary items, basically I would like to know the file names and place to put each item in according to this(starting from "In your main Activity file...").For example, which is the main Activity file?
If you want to create Xamarin.form app with Azure, you can take a look the following article:
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-xamarin-forms-get-started
And you could be confused about xamarin.form folder, when you click corss-platform---Mobile App---OK, your solution will be created with four projects, you will have three platform-specific projects and one Shared Project. The Shared Project contains the application logic as well as all the Xamarin.Forms code that will be in charge of creating the screens (Page objects) of your application. More detailed info, you can take a look the following article---Creating basic Application.
https://code.tutsplus.com/tutorials/getting-started-with-xamarinforms-basics--cms-21564
Are there any guidelines and best practices for organizing Visual Studio Team Services for a new cloud app? I'm planning on creating a WebAPI solution for REST services, a Xamarin Forms solution for mobile client, an MVC solution for web, and finally SQL scripts. Ideally, I'd like to account for future apps with their own source code.
Dev
App1
WebAPI
XamarinForms
MVC
SQL
App2
...
...
Test
Prod
Another approach is to create a project per App
App1
Dev
WebAPI
XamarinForms
MVC
SQL
Test
...
Prod
...
App2
...
I have also seen people put everything into a single giant project under a single collection. So, instead of creating Dev, Test, Prod projects in the first tree, we'd create them as folders. Same with the second tree. Why would I not want to create multiple team projects?
I'm not a TFS expert, but I'd like to get started on the right foot.
P.S. I've seen a few similar questions on SO but did not think they answered my question, especially the part about not creating team projects.
Visual Studio Team Services (and Team Foundation Server on-premises) support the notion of Team Project Collections, Team Projects and Teams.
A TPC is the highest degree of separation. Currently, you get one DefaultCollection on VSTS. Within this collection you create separate Team Projects. Within a Team Project you have one or multiple Teams.
The current best practices state that a single Team Project is the easiest to work with. In short, this allows you to more easily share code, work items and other assets while still having separate backlogs and code repositories.
For a more detailed explanation see a couple of blogs on this subject such as:
Why You Should use a Single (Giant) TFS Team Project
One Team Project to rule them all
Many Git Repositories, but one Team Project to rule them all
In your scenario, I would absolutely go with one Team Project and then multiple Teams for each separate application. In the top level team you can then schedule Epics and Features and distribute these to the implementation teams.
If I started such a project today, I would also choose Git for Source Control. Git and TFVC are both supported and TFVC is going nowhere. Git however does have some advantages that I think are very attractive.
Regarding your folder structure. If App1 and App2 need to be released together, they should sit in a shared branch. If they can be released separately, they should have their own branch.
The ALM Rangers have a great document on Version Control that explains different Branching models. This is freely available on CodePlex.
I have built two projects in my VS solution. One is a MVC web applicaition and other one is a standard C# windows form project. I want to transfer data both ways. For exmaple the input from my MVC web application to the form and then output back to my web application from the C# form project. However, I can only do refrenceing from one side and access the static variblias of only one project from another. To achieve my goal, I need to do circular referencing which VS is not allowing me. Is there a workaround to my solution.
PS: My main goal is to access all the static members of every class into every other class in my whole solution.
Separate the static functions in a separate library and then reference that from windows or web application. That way you will also know what are common functions and what functions are specific to those feature or class.
It is not a good design to let "access all the static members of every class into every other class". It violate OOPS principles.
If its shared data save it to any repository and access it from there from both of your application.
I'm new to SharePoint and trying to get my head around this. I have a simple Web Part project. I also have a custom Data layer project that uses the Microsoft Enterprise Library for data access. In the Web Part project, I am adding a reference to the Data layer project's assembly. I specified in the Package of the Web Part project that I want my Data layer's assembly to be deployed. I can verify this works by using standard ADO.NET classes and not the custom MS library. If I deploy to the SharePoint server (which I have 100% access to) using the Enterprise Library, I get the error message:
"Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Data"
What steps do I need to take to ensure this project and all future projects on the server can easily gain access to the Enterprise Library for data access?
Thanks!
You did everything correct until a certain point: Deployment.
When deploying external DLLs, which shall also be put into the GAC or somewhere else, you need to package them with the WSP aswell. This has become very easy with Visual Studio 2010:
Open your Package
Click on "Advanced" (on the bottom)
Add your external DLL and maybe even SafeControls for the web.config
I have a rather large project developed on Sharepoint and Project Server, designed as a multi-tier application. I programmatically manage web parts on certain web part pages. According to the choices of the user in one of the web pages, appropriate web parts are added to the web part collection of another web part page. My problem is that I simply do no know where to manage the web parts, should I do it in the BLL and then have the assembly containing the business logic reference the UI assembly where the web parts are? (I need to instantiate the web parts when adding them to the collection, since I do not want to use hard coded strings representing the web part dwp.)
It really depends on what pattern you're using for your BLL and UI layers, and how strictly you want to follow it.
If you're doing a MVP pattern then I'd suggest that you have the Page implementing an interface which has one (or more) of the following options:
A stack which the Presenters to load are added to
A Load_WebPartName event for each web part which then should be called to indicate which webpart(s) need loading
To be strictly MVP you should not reference the following assemblies in your BLL project:
System.Web
Microsoft.SharePoint
Microsoft.SharePoint.*
(All SharePoint assemblies would be in either the Model or UI projects, the BLL is just connecting to the appropriate hocks)
Can you package the web parts as a feature or set of features and then simply manage the feature(s) activation/deactivation through the web part manager class?
Any programmatic massaging of the web part that needs to happen on the appropriate web part page can be handled in the feature receiver, so your manager doesn't need to be so aware of the web part UI.
HTH,
jt
Web parts are generally best managed using the feature/solution framework. You may treat the webpart classes you write as any other web control, and thus a part of the ui layer. I generally keep the information in the xml files (the .webpart or .aspx files) to a minimum. If you are managing them exclusively, you don't really need to use declarative code files at all.
The short answer: webparts are sharepoint specific ui, and should have no knowledge of the business layer.
The short answer is probably "no, you should not do this in the BLL." A purist might argue that while the BLL may rightfully determine what a user can or can't do, it is up to the UI tier to determine the appropriate web parts to be displayed as a result.
For example, the BLL might determine a user's capabilities and expose them as roles, or permissions or something else with domain-related meaning (e.g. timesheet approver role, approve timesheet permission, etc.). These might then be mapped to a set of web parts by the UI tier (e.g. timesheet approval web part). In this way, the BLL effectively determines the users capabilities and the UI tier determines the UI for those capabilities.