I don't have any idea how to connect mvc application with outlook so if some know
How to Connect MVC .net project with Outlook Mail.
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
If you deal with Exchange accounts you may consider using EWS or Graph API. See Explore the EWS Managed API, EWS, and web services in Exchange for more information about EWS.
Related
Long-time .NET 2.0 developer, but a little rusty on the new web services the kids are running around with today. I'm building a new ASP.NET 4.5.1 intranet app and need to wrap my mundane ADO.NET data-access-layer of CRUD functions in web services that allow it to be consumed by JavaScript functions on the client-side. It's my understanding that REST is preferred over SOAP for new stuff.
Does Visual Studio 2013 have good projects for this? Does someone have a good guide or link to learning this in VS?
if it's relevant, all my BAL and app code is .NET 4.5.1, SQL Server back-end, and the current task is for facebook-style notifications -- alerts of new notifications, flagging notices as read, etc.
Using VS 2013, you are already in a great place to begin the transition to RESTful services. Just start a new "Web Application" project, and in 2013, you'll get a secondary set of options. Select "Web API" and you have all you need to get started.
Next setup your Web Api controllers to implement "ApiController" and start adding your GET, POST, PUT, etc methods that are accessed by using those verbs against the endpoint you created.
Start here for a sample or two... http://www.asp.net/web-api For a quick overview, there's a free overview from pluralsight. I personally made the transition using some of their paid courses, which were totally worth the subscription, but that's me, you may learn differently.
As for alerts and potential for cross site requests, look up CORS and SignalR samples there, both of which are easily integrated into 4.5.1 apps.
REST != SOAP at all. REST embraces the http protocol and soap embraces remote procedure call style communications and all the soapy header stuff. You can be RESTful via WCF (which is what it sounds like what you are eluding to) but Web API is a natural fit \ successor of web services \ soapy like communications.
Here is the official web api link:
http://www.asp.net/web-api
And a getting started:
http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api
I'm working on a project where we will be interacting with the ReportService2010 reporting web service under SQL Server 2008 R2. In the past, I've worked with the ReportService2005.asmx, and my problem here is, I can't find any reasonable examples on how to render a report with this new (2010) reporting web service.
When using the 2005 web service, there was a "Render" method that was provided when creating your proxy with the wsdl.exe utility. Is there an equivalent method (or set of methods), to accomplish the same thing using the ReportService2010 service? Or are there any decent examples of an end-to-end intialization and calling of the new proxy?
Even MSDN doesn't have much information, and in certain parts of the ReportService2010 API docs, there are old snippets of code that were only applicable to the 2005 web service.
UPDATE: A better question might be how have things changed between SSRS 2008 and SSRS 2008 R2 with regard to calling the report service(s) programmatically...I can see that even under SSRS 2008 R2, there still exists a ReportService2005.asmx, as well as a ReportExecution2005.asmx, but there is not a corresponding ReportExecution2010.asmx.
sigh
SOLUTION UPDATE:
After talking to someone at my company, I was informed of the following:
The 2006 web service was introduced to support sharepoint integration in 2008.
The ReportService2010 web service was introduced to merge all the functionality introduced by 2006 with the 2005 web service.
ReportService2005 web service will continue to be used for report execution. I don't know why, but something tells me it has to do with business decisions for backwards compatibility. My coworker said we are intended to continue to use ReportExecution2005 for rendering, and ReportService2010 for all other functionality (querying the SSRS server for reports, params, etc).
Unfortunately all the above information was culled from a variety of links, none of which concisely stated all of the above. It's the kind of thing that you would normally assume a vendor to explain to client developers.
SQL Report Server provides 3 different endpoints.
ReportService2010: Provides the APIs for managing a report server that is configured for either native or SharePoint integrated mode.
ReportExecution2005: Provides the APIs for running and navigating reports.
ReportServiceAuthentication: Provides the APIs for authenticating users against a report server when the SharePoint Web application is configured for Forms Authentication.
Thus, in order to render the report you must use this one ReportExecution2005.
Here it says what I have pasted above: http://www.blograndom.com/blog/2011/03/reportservice2010-asmx-is-not-the-only-end-point/
Here you can find an example (it has some errors though) to get started
http://blogs.msdn.com/b/christophputz/archive/2010/05/07/accessing-ms-reporting-services-with-java.aspx
Good luck!!
I want to build a custom document management web application that ties in with sharepoint for the actual document versioning and storage. I'm hoping for something like a sharepoint widget that I can plug into my web application that would allow me to tie in with sharepoint and download documents, make edits to them, and upload them back to sharepoint, with sharepoint handling all of the versioning and storage.
Basically I'm looking for a sharepoint API.
If WSS is the answer to this, are there licensing issues that I need to consider?
Thanks.
The best way forward is probably to use SharePoint's web services as that way your application can run on a server that doesn't have SharePoint installed.
Regarding Licensing, as long as you are licensed for Windows Server then WSS is free. However, depending on what database you use you may need to make sure that your users are licensed for SQL Server. Have a look at these links:
SharePoint Connections
Technet
Eggheadcafe
Wouldn't it be easier to do some development to customize SharePoint to your needs instead of just using it as a backend?
If it's SharePoint 2007 you're talking about, then on the server side you have the SharePoint API (Microsoft.SharePoint.dll) and on the client side, SP provides web services for manipulating lists, libraries, users and most other things you might need.
As Jeremy said, getting data to and from SharePoint through the Web Services, requires you to write CAML queries, but it's made easier by the help of tools such as this free CamlQueryBuilder
There's loads of documentation on both the API and the web services online.
If you're planning on using SharePoint 2010, all this will be quite easier, as more options are available for developers, e.g. API for the client side as well as the server side. Also new in 2010 is LINQ for SharePoint, which IMO really rocks!
Sharepoint is accessible with CAML Queries in that you can create, modify, and delete any object in Sharepoint with this.
You could create your own front end and just communicate to sharepoint.
As far as licensing, WSS comes with any Windows Server OS, so your client would just buy a license to the OS and be fine.
I have a partly developed asp.net application, but now the client wants it to be developed in azure. How much of the existing code can be used in developing the application in azure.
What challenges could we possibly encounter when we try to port an existing asp.net application to azure? Are there any other alternatives to azure in cloud computing?
For an asp.net application, you can certainly port that to Azure. Your core logic will port in a relatively straightforward manner, and you'll gain the many benefits Azure has to offer. With the June 2010 release, you'll also have .NET 4 support, along with IntelliTrace for debugging.
However, as you begin to plan your Azure migration, there are several considerations you'll need to think about (none of them insurmountable, and several relatively simple to deal with):
You have to deal with ASP.NET Session State management across your web role instances (which isn't supported out of the box, except for inproc). You'll also have to set up and use the role and membership providers (see here for more detail). EDIT: You now have access to both AppFabric Cache for session state as well as SQL Azure, part of the Universal Providers included with the Windows Azure SDK+Tools.
You have to examine your SQL backend for incompatibilities with SQL Azure (such as scheduled jobs,since there's no SQL Agent support). SQL Azure differences are documented here. You'll also need to consider the SQL Azure size limit of 50GB, which might require you to offload content to Azure blob storage. EDIT: You can run your SQL Server database through the SQL Azure Migration Wizard for compatibility-testing.
You need to configure logging and diagnostics, preferably with Trace output, so that you can retrieve this data remotely.
You need to think about how you'll monitor and scale your application. All information you might need for scaling is available to you (performance counters, queue lengths, etc.). Check out WASABI - the auto-scale application block, part of Enterprise Library. You can also subscribe to a service such as AzureWatch.
You'll need to think about caching, as there's currently no out-of-the-box caching implementation that runs across instances of your web role which is now provided as a service. Read details here, as well as an FAQ here.
Do you need SMTP support? If so, there are details you should read about here. SendGrid recently announced a free-tier promotion for Windows Azure.
Are you hosting WCF services as well? If so, check out this site for further details (specifically the Known Issues).
So: yes, there are some things you need to concern yourself with, but Azure is a great platform for hosting an asp.net application and you should strongly consider it.
It should be very easy to port your application to Azure--especially if you're using a SQL back-end. The code could run almost without modification. You'll need to create an Azure installation package for the project and configuration file.
If your application makes use of persistent storage (other than SQL Server), you may have to rework that code somewhat. However, the platform now has drive storage, which simulates a file system, so this should be fairly easy.
Another issue to watch out for is web.config. If you make heavy use of this for runtime customization, you'll have to rework that too. You can't deploy single files to your application in Azure, so the recommended approach is to migrate these sort of settings to the Azure config file.
The hardest thing you're likely to encounter is external applications. If your app relies on launching other processes, then this will require some serious redesign.
Azure now supports Web Sites as a deployment type. Basically this allows you to publish any standard Asp.net (and other supported like PHP etc) application to Azure and have it as a scalable server. See this article http://blog.ntotten.com/2012/06/07/10-things-about-windows-azure-web-sites/
Many of the benefits of Azure without having to introduce Azure specific code/Project to your existing application.
Also this question here What is the difference between an Azure Web Site and an Azure Web Role
This is a pretty vague question but I'm struggling a bit to get my head around what is involved in cloud hosting.
Say for instance if I had an asp.net web app using:
- Webforms
- linq to sql
- an sql server database
- Calling some external restful webservices
What would need to be done to host it on a cloud service?
Are there specific code changes that would be required and do these need to be considered in the initial design?
Can sql server and linq to sql be used in this type of setup?
What platform if any would be best suited?
in it's most basic form, Azure is just a highly available web-hosting environment - if you have an ASP.Net web application, you can deploy it to cloupapp.net and it should work.
To try it out, get yourself a Vista/7 machine, download the Azure SDK and VS Tools, and create a new Azure application. There are 2 main parts at this point, the Cloud project, and an ASP.Net Web Application. The ASP.Net will have a "web-role" relationship with the Cloud project. This is as it sounds, it is the visual front-end to the Cloud application, that interacts with visitors.
You can, at this point, just leave it there - it's a normal ASP.Net application with very good hosting. Your SQL connection strings should work, though you may want to consider SQL Azure. You can also host WCF services.
As Manoj points out, Azure does have a different programming model which you can take advantage to produce very robust applications. Azure also has the concept of Worker Roles, which are similar to Managed Services, in that they perform processing without a public interface. Instead, your web-roles take the requests, place them on the Queues, and the worker-roles then pick them up, process and send back responses.
It's a very powerful system, which I haven't fully explored, but the good news is that you don't have to be an immediate expert in the whole system, but can create simple ASP.Net sites as web-roles, deploy those then expand from there.
Have a go, it's well worth it
Toby
AppHarbor is a .NET Platform-as-a-Service. We can host your ASP.NET websites more or less un-modified and without the Visual Studio plugins and other crud that Windows Azure requires.
It depends on what type of cloud hosting are you looking for. There is some cloud hosting which will just give you space for application data like Amazon. While Azure gives you complete application framework which supports your application to be hosted in cloud. But programming in cloud is different programming paradigm than in traditional web form. You will have some limited classes from .Net framework available but better resources for scalability.
You cant directly use sql server in azure application. What you can use SqlAzure services.
Just referring a book which i feel would provide you the answer
Cloud Computing Book
EDIT :
Check this microsoft link
Ramp Up
yes, it is supported and live demo of Asp.NET 4.5 Web Forms available on Microsoft azure websites... you can visit this link for detailed information
Create and deploy a secure ASP.NET Web Forms app with Membership, OAuth, and SQL Database to Azure App Service