I need to write a component to retrieve emails from a given Exchange Server account. I don't have a local copy of Exchange and I can't easily get access to the production server. What options do I have? Is there a cut down / free development version of Exchange? Is there an API that I can code against and then just deploy and test in live?
You can download a 120 day evaluation version of Exchange 2010 from http://www.microsoft.com/exchange/en-us/try-it.aspx
Threre is also a link on that page to set up a test against an online version
Without having a staging and/or test environment with another instance of exchange running, you might be out of luck.
I would also approach this from a design stand-point. You likely want to test your logic independently of Exchange (i.e. you don't want to test Exchange and you may want to test code that uses your code that interfaces with Exchange but don't necessarily want to re-test the code that interfaces with Exchange--and take the performance his of a round-trip to/from Exchange). So, I would look at Dependency Inversion and mocking as a means of separating your code from being directly dependant on a existing, available, and operational instance of exchange running.
There is no way you can simulate it (as far as I know via 3rd party apps that is), however you can sign-up for the free Office 365 beta (or any other hosted exchange trials) point your Visual Studio to
http://[whatever pod hosting your mailbox].outlook.com/ews/Exchange.asmx
add it as a WebService reference and get on with your development. Best of luck.
Related
My goal is to update the Certificate for Exchange Servers from within a C# app, just like the Enable-ExchangeCertificate PS Cmdlet does.
I've already written an updater for IIS, which uses Microsoft.Web.Administration to access and manipulate IIS Sites and Bindings. I've searched through Google and VS Libraries for Exchange API tools, but without any luck. I can only find References to EWS (Exchange Web Services), which can't update the Server Certificate AFAIK.
Is there any API that can be used? How does Enable-ExchangeCertificate provide the functionality? I'm also thinking about just using the PS Cmdlet if all else fails, but I'd like to have a standalone app to rely on. No remote server management needed, localhost-only is fine.
tl;dr How to update a local Exchange Server Certificate in C#?
EDIT I'll look further into the EWS API (https://github.com/OfficeDev/ews-managed-api/blob/master/README.md), it looks like it might do the job. It provides Assemblies to access EWS data, but I haven't found any API Calls exclusively for Certificate Management.
There are multiple parts in MS Exchange which aren´t covered by an API. Mostly this is due to security reasons or as it´s quite complex and therefore no API needed (e.g. Exchange Schema update).
The normal Microsoft way included only two steps:
Make a Backup of the current configuration & SSL cert (Optional)
Import the certificate
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path
c:\certificates\YOUR_CERTIFICATE.cer -Encoding byte -ReadCount 0))
But some use MMC and that's working as well (so you might check for an API for MMC for this part).
Enable it
Enable-ExchangeCertificate -Thumbprint
1234ae0567a72fccb75b1d0198628675333d010e -Services POP,IMAP,SMTP,IIS
I would assume that there is no such API as its not really needed to have one. Normally an SSL certificate is valid for 3 years. So you need to run the command above 1x every 3 years and a 3rd party access to this part wouldn´t make any sense as it wouldn´t be often used and therefore Microsoft haven´t build one.
To give you more infos here. The SSL certificate information for Microsoft is saved in two locations. One in the local Regestry and one in Microsoft Active Directory (see here: uses the local instance of Active Directory Lightweight Directory Services (AD LDS) to read and write data). Dealing with changes to the ActiveDirectory without the way Microsoft supports might be VERY risky and would mean that Microsoft do not offer any support if that caused a problem. So I would use the powershell approach Enable-ExchangeCertificate in your app.
P.S. I would never ever run an unknown plugin on my Exchange server which do replace an SSL certificate which I can do via a simple powershell command. The plugin could cause a lot of other issues and can contain a lot of stuff which isn´t so "nice". So before you wast your time into that project think if there is really an audience for it.
I have a windows network (not connected to domain) and I need to provide some automation on each PC at certain time of the day. There are several tasks - launch executables, managing FS, transfering files. All this actions must be implemented via RDP, using C#. What is common approach to achieve this? I don't have experience using RDP within software. So are there .NET classes or free libraries I can use to get RDP functionality in my software. Thank you!
All the tasks you have listed relyed much more on security issues for machines within your network and a user logged-in priveledges a rather than a usage of RPD.
Within a windows domain the tasks like yours are usually delegated to ActiveDirectory administration and policies.
In case of a not Windows Domain Network you will need to use a mechanism that will be presented in following configuration:
a client installed on each particular machine under proper permissions. The client should implement a subscriber pattern.
a server installed on a "commander" machine. the server should inplement a publisher pattern.
There should be a lot of ready solution that should implement the concept of content disribution and starting specific scripts. I think that your investment in such tools research and evaluation will be much more time- and cost- effective rather than writing an app that "uses RPD functionality"
But if there is a reason that prevents usage of 3rd parties, I would go for implementaion of WCF service that will be installed on all clients. This service should be "trained" to do all your suff on client. Server side you will need an appliaction or a service that will publish events for clients or trigger known clients methods.
We have an instance of SQL Notifcation Services for which we have written a custom delivery channel. We had this process up and running in our QA environment running Windows Server 2003 with SQL Server 2005. It took a little bit of tweaking to the get the custom DLL trusted however we got it all working.
We have since deployed this code to our Live environment. This runs Windows Server 2008 with an Instance of SQL 2005 for Notification Services but then we have an instance of SQL 2008 which hosts the actual DB instance for Notification Services. Notification Services works as it should however we cannot get the custom DLL to be trusted as a result the custom delivery channel won't work. We simply get the error
That assembly does not allow partially trusted callers
We have tried using the .NET configuration utility and caspol.exe to give the .dll full trust with no luck at all. The .dll is compiled as a .NET 2 dll as notification service requires this.
We are pretty much out of ideas at the moment and hoping someone can suggest something?
We have managed to fix our issue. It would appear that Windows Server 2008 is stricter in its implementation of code access. By giving granting access to the .DLL by it's strong name rather than it's path allowed Notification Services to access the code.
Notification Services was not at fault.
I think you have one of two choices:
Embrace SQL 2008 and get rid of Notification Services because it was deprecated. Use Reporting Services or SSIS to do what you need.
Revert back to SQL 2005.
IMHO, I'd go option 1. Continuing to build with deprecated tools is going to quickly find you in a situation where support (community or vendor) is going to be extremely hard to come by.
update
This was too long for comments.
Not to beat your head too much, but continuing to develop applications for a technology that was EOL'd (end of life) over 3 years ago was the first mistake. The EOL statement was made quite public.
The second was having a QA environment that is radically different from production. Before deploying anything to production, the QA environment should have been identical... same type of hardware, same OS's, same server versions and patch levels. Otherwise QA is a joke, as you've found.
Now, as to the "resolution", there really is only one path: Revert your production environment back to SQL 2005 with the appropriate patches in place.
I wish you luck.
I have written a commercial WCF web service.
I would like to give the service to another person to test independent of the application that will be using the web service. This is because a third party is going to be building that app and we don't have access to it at the moment.
Another thing to remember too is that the person I want to hand this off to for testing is a non programmer. That is important.
So are there any tools out there that can subscribe to a WCF web service, and recognise what data needs to be inserted, and create a GUI to try out different combinations of data?
Thanks.
I typically use SoapUI for that purpose. You can also create test suits with it and it's free. Alternatively you can use the Microsoft WcfTestClient.exe that comes with Visual Studio since version 2008 I guess...
WCF Test Client (WcfTestClient.exe)
You can find the WCF Test Client (WcfTestClient.exe) in the following location: **C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE**
Using the WCFTestClient Tool to Test Service Operations
You can consume a web service with Office InfoPath, or write a simple test application in C#.
In general, you need to publish the web service meta data (normally as a wsdl end point) - this metadata should enable any client to get all the information needed to make calls to your web service.
This may help: http://msdn.microsoft.com/en-us/library/ms734765.aspx
As may this: http://keithelder.net/blog/archive/2008/01/17/Exposing-a-WCF-Service-With-Multiple-Bindings-and-Endpoints.aspx
Update:
From the comment, is appears that you need non programmers to be able to test your service and are looking for a user interface that can be used to work directly with your web service (and automatically adapt to changes). As far as I know, there is nothing built it that will do this for you (though the old asmx services created web forms that could be used).
So you are looking for application that will create UI for manual testing of your service? Not sure if something like that is available for free. SoapUI PRO is able to do that but in contrast to common SoapUI it is not free. Basic SoapUI version requires tester to write XML messages directly.
You should think about your requirement. You want tester without any programming knowledge to test artificat which is for programmers - not for end users. You probably have to buy some tool or write your own solution to support such test.
I am working on small application of sharepoint.
There two ways in which WE can access Sharepoint data:
1.By Using Microsoft.Sharepoint.dll In this case you need to do coding on same machine (windows server).
2.Second way is to use Sharepoint Web Services. This will allow developer to do developement work on different machine.
But which way i should prefer?
Regards,
Jene
That all depends on what you want to do and where you want to run it. The SharePoint object model (Microsoft.SharePoint.dll) is substantially faster than the web services, but like you said, it only runs on the SharePoint machine. So, if you are on the SharePoint machine, definitely use the object model, otherwise, use the web services.
You don't have to develop on the same machine, but you do need to develop on server with SharePoint installed. I can tell you from experience that the web services are not the nicest to work with...I would use the SharePoint object model.
Just saying "development on my production server" makes me cringe. To that end, you may want to look into using some kind of VMWare to do your development on. You can install Sharepoint and Visual studio on the virtual machine to do your development. The only issues with you doing it this way is that you are not going to have the same content (the lists and other user created libraries/sites), but you can easily make your own to resemble your production environment (as is usually the case with most dev environments).
One thing to consider is database connections. If you create a seperate application using the SharePoint DLL then your DB connections will be managed through your application. So your application will have to run using an account that has read/write privs to the SharePoint database.
If you use the web services then this is not the case since the database connections will be handled inside the IIS Application Pool (like a normal SharePoint web site).
Unless you are unable to deploy solutions to the SharePoint server due to corporate security policies, shared hosting or similar, you will want to use the object model. Get a SharePoint VM (one of the evaluation virtual pc downloads from Microsoft is a good starting point if you haven't set one up before) and WSPBuilder, and it's easy enough to make packages to be deployed to the server.