Where can I get the latest Microsoft.Exchange.WebServices.DLL? - exchange-server

I'm trying to use the latest Exchange Web Services DLL, however when I search my hard drive I see many versions of Microsoft.Exchange.WebServices.DLL, the most recent being version 14.0.650.7 with a date of 1/24/12.
I want to rebuild my machine but can't find an official place to get this DLL. I attempted to download the latest SDK I don't see any DLL to use, nor is there any CHM for me to use.
Where can I get the latest version of Microsoft.Exchange.WebServices.DLL?

Current version of the EWS Managed API is 1.2. It seems that Microsoft sometimes forgets to update links to the newest download which makes it hard to find out what the newest version is but I usually go to www.microsoft.com/downloads and search for "Exchange Web Services Managed API" whenever I need a fresh download.
UPDATE:
EWS is on NuGet:
http://www.nuget.org/packages?q=EWS

This is an old question, and the two answers by the OP and #JakobChristensen do answer the question. I'll just mention that I'm finding the situation fairly confusing.
I recently (manually, not via NuGet) downloaded the current NuGet version, which they currently call "2.2.0".
https://www.nuget.org/packages/Microsoft.Exchange.WebServices/
But the internal file/product version on the .dll is 15.00.0913.015.
According to this page
https://msdn.microsoft.com/en-us/library/office/dn528373(v=exchg.150).aspx
the file should be placed here:
C:\Program Files\Microsoft\Exchange\Web Services\2.0\
So that's where I placed it. Later, when playing around with a Microsoft sample program I noted that it did indeed reference the file at that location.
But another Microsoft sample program referenced the file in the GAC!
C:\WINDOWS\assembly\GAC_MSIL\Microsoft.Exchange.WebServices\15.0.0.0__31bf3856ad364e35\Microsoft.Exchange.WebServices.dll
This version had file/product version 15.00.0847.030.
I'm not sure how that file got there, probably part of a Visual Studio installation.
There's also something called EWSCore, which is apparently a forked version of the official EWS with some bug fixes.
https://www.nuget.org/packages/EWSCore/
My current decision is that I'll consider the official NuGet version to be the version I'll standardize on, and manually download it to my development PC and my build PC and place it here:
C:\Program Files\Microsoft\Exchange\Web Services\2.0\

Options
If you use .net framework, there is a nuget package "Microsoft.Exchange.WebServices 2.2.0" here https://www.nuget.org/packages/Microsoft.Exchange.WebServices
If you use .netstandard/.net5+, you need to go the Github open source project "OfficeDev /
ews-managed-api" here https://github.com/OfficeDev/ews-managed-api , and there you download the code, and compile it. However, this project is targeting .net3.5. So, you need to convert/upgrade it to .netstandard/.net5+ manually and compile it for your self.
!! Update !!: I took the version as of date of this post from GitHub. Replaced Old Style project with SDK project. Target framework set to netstandard2.0. Added packages System.DirectoryServicesandSystem.Security.Cryptography.Xml. In files, I had to remove few namespaces that not compatible, but were not used. Removed AsImageinPhoto, this is public image retrieving method, not needed - it only converts byte array. And fixed loading issue with Assembly.GetExecutingAssembly().GetTypes();`
Type[] types;
try
{
types = Assembly.GetExecutingAssembly().GetTypes();
}
catch (ReflectionTypeLoadException ex)
{
types = ex.Types.Where(t => t != null).ToArray();
}
I also deleted or excluded from project bunch of files related to documentation, fxcop, and assembly info.
And then it worked for sending emails with different API versions. Reading emails is not tested yet.
There is a third option. Nuget has a package "Microsoft.Exchange.WebServices.NETStandard 2.0.0-beta3" But this is not an official Microsoft code. https://www.nuget.org/packages/Microsoft.Exchange.WebServices.NETStandard/2.0.0-beta3
!! Update !!: Got this version and compared to the original code in option #2. This code has more changes than necessary to convert to .netstandard. It has some async stuff added.

Related

The procedure entry point could not be located in the dynamic link library MetropolisULiveTile200.bpl

Today I start getting this message when I open Delphi XE6.
The procedure entry point #Idstackwindows#TidStackWindows#NetworkToHost$qqrj could not be located in the dynamic link library C:\Program Files (x86)\Embarcadero\Studio\14.0\bin\MetropolisULiveTile200.bpl.
I answered Yes to "Do you want to load it next time".
When I look in the folder I see that the MetropolisULiveTile200.bpl is in the folder.
I haven't installed anything new since 9/24/2020, when I installed the latest version of Indy. I have used Delphi XE6 every day since I upgraded.
It looks like any program I have are building and compiling without any errors.
I search the internet, but was not able to find any with the same problem.
This issue is documented in Indy's installation notes:
In D/CB/RAD XE3+, Embarcadero's Metropolis UI LiveTile framework is compiled against the Indy 10 packages that ship with the IDE. Installing a new version of Indy will render LiveTiles unusable, as it will not be able to load the Indy packages anymore, and LiveTiles cannot be recompiled by end users. If you need to use LiveTiles then you will need to maintain the original Indy 10 packages for use in LiveTile projects. You can use a separate installation of Indy 10 for non-LiveTile projects. This has not been addressed by Embarcadero yet so Indy 10 upgrades and LiveTiles can co-exist.
If you were not getting this error between 9/24 and today, and now you are, then you probably opened a project today that has a dependency on (or at least enables) the LiveTile package, whereas projects you worked on earlier do not.

Visual studio complains about spatial types

I have these CLR types installed on my local https://puu.sh/yEWG5/b4f77fba7b.png
Also, I have SQL server 2016 installed on my local system but when I try to run the project I get error as below
https://puu.sh/yEWQm/78a4220830.png
Can someone help? I tried installing latest nugget package from https://www.nuget.org/packages/Microsoft.SqlServer.Types/ but it did not help.
Though I am able to add a column of type geography in a table in my local database. It fails at runtime when I run my project and error comes as below
https://puu.sh/yEWQm/78a4220830.png
According to the docs if you have installed the CLR Types it should load from the GAC so I'm not sure why that didn't work for you. (I would check that you have the correct version as your dependency)
However, we do use the SQLServerTypes in our app without installing the CLR types by using the following method (this method is described in the readme.htm that comes with SqlServerTypes).
Grab the SqlServerTypes.nupkg and extract it to a folder lets call this folder SST from now on.
(Locations of the files I talk about in the following steps may differ from version to version but, the principle is the same)
Create a SqlServerTypes folder in your project
Copy the SST/nativebinaries/x86 and x64 folders into your new SqlServerTypes folder
Also copy the files from SST/content (you should see Loader.cs and readme.htm) into the SqlServerTypes folder.
Now all you need to do is call the Loader when your app boots up.
We do this during our autofac setup by making this call.
Utilities.LoadNativeAssemblies(AppDomain.CurrentDomain.BaseDirectory)
You may need to adjust the param passed into this method to work with your application. If the correct path is used you should have access to the spatial types in your code.
edit: It may be possible to just call the LoadNativeAssemblies straight away (and avoid all the work I posted above) if you have installed the nuget package in your app but, I have not tested this as we are stuck on an old version of SqlServerTypes.
Because i cannot put a comment i have to put a answer, you can check that, that article and this, this, this and this answers, i hope they guide you to someting usefull.

olingo-odata4-js project setup

I'm trying to follow the directions to setup olingo-odata4-js on a windows 8 machine.
http://olingo.apache.org/doc/javascript/project-setup.html
First Problem
After installing the main modules navigate into the folder /grunt- config/browserify_transforms/stripheader and call again npm install
But there is no such directory anywhere in the cloned repo.
Second Problem
When I open up the solution in Visual Studio, the gnuget package manager asked to restore the packages. However, the following error occurs: "unable to find version 6.0.0-beta1 of package Microsoft.Odata.Service"
Anyone successfully go through the setup? Everything looks clean and well written. I'm sure I'm just missing something.
it is a bit long story about the missing Microsoft.OData.Service 6.x, it does exist but is not officially released to public. unlike Its previous version that is for odata V3 protocol, 6.x library is for odata V4 protocol, since Microsoft OData team decided to move away from WCF Data service, and instead wanted to recommend RESTier for OData V4, so 6.x's service dll was not released.
that is why Apache Olingo doesn't make it public either. but if you need, we can provide private bits to you for running olingo-js tests (as a temp solution).

Source code is different from original version

We are working on a .NET application and recently started using Git for version control.
Our latest release was tagged in Git, and now i am trying to debug some issue.
Here's what i did:
Installed the app (from the release) on my Pc.
Checked out the tagged release version.
Started VS and attached to the process.
Placed breakpoints over some part of the code.
I am getting the message: "Source code is different from original version", however this is the actual code that was compiled to release this installed version.
What am i doing wrong here?
using VS2008 if that matters.
BTW: What is the mechanism that is used to compare if the binaries are different from source code?
When cloning the repo from Git, for example, it will change all files/folders date to the current date. Is this value (datetime) used to determine source code vs. binary?
The problem was i didnt use (or store) the original symbols for this release.
I previously thought symbols only contained source code line information and were not needed to actually debug the program under VS. apparently i was wrong.
A good resource on symbols for anyone who's looking into problems with them: http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx
This post also contains a few other links to MSDN Magazine with more valuable information.

Make Visual Studio not care about DLL versions

Is there a way to make visual studio not care about dll versions? Is this a bad idea?
I am resetting up my dev machine and I just installed the latest version of Pex and Moles (version .92). All my projects are on version .91.
We are in the middle of a release and don't want to upgrade right now. Also, I cannot find an installer to version .91.
When I try to compile I get a message that I am missing the reference. (Hence this question)
The version is important.. By definition, there is a difference from each released version to the next (or there would be no need for a new version). Your program may not perform correctly if you are expecting one version and instead have another.
This was a part of what was known as "DLL Hell" in the pre-.NET days... If you needed to use a third party component (Crystal Reports Viewer is one we always had to deal with), you would just use the reference to whatever installed version was on the user's PC. Our retail locations had to have a specific version of Crystal Reports for their bookwork reports to print correctly, and because of that, we had to hold on to an old version forever.. Upgrading Crystal on the PC broke the vendor's bookwork app. On my first ever PC, I had several applications break when I would install or upgrade another. In particular, Real Player broke my telephone answering machine software. Goofy stuff like that...
So, the version IS important, even if it is an annoyance. It's also why I have a bias against third party tools that I have no code for, and can't recompile myself.
If you look at the properties of a referenced DLL, you will see a property "Specific Version". If you set it false, it doesn't track the specific version in the project file.
For this to work, you have to somehow fix the references where ever they are used. You can do this by opening every solution and fixing the references (at which time you could also just update the references to the correct version, paying heed to David's comments).
If you have a lot of solutions, you might use a tool like sed (see this post for windows versions of tool like this Is there any sed like utility for cmd.exe) to just update the project files as needed all at once.

Resources