How do I check in .net core (console app) if a given AD-group already exists ?
And how to create it, if not existing ?
If you're running your code on Windows as specified in the tags, quite easy. Install Windows Compatibility Pack nuget package and among others you'll get System.DirectoryServices.ActiveDirectory namespace with the classes that are available in classic .NET.
See this article for many code samples.
Related
I have been working with the HL7 FHIR .NET API reference implementation - utilizing the existing resource models embedded in the library. Now, I am trying to use the Forge tool to modify the resources (contraints/extensions) to suit my requirements.
I noticed that the HL7 publishing mechanism does not generate C# models from DSTU 2 onwards and was wondering - what is the best way of converting profiles created using Forge into C# resource classes such that they may be included into the HL7.Fhir.Model assembly that is part of the reference implementation.
The generation of the models not being part of the official build is correct.
This has now moved to https://github.com/ewoutkramer/fhir-net-api where the rest of the API is maintained more easily.
It is done using T4 templates on the output from the official builds.
There is a simple process for updating the models with the new versions of the spec, and we keep it fresh as people need it, and for each connectathon we publish a new build in NuGet and have a branch of the code in GitHub.
(Its a powershell script that downloads all the latest build outputs and puts them in the appropriate folders, then you need to run the t4 templates in Visual Studio)
Such as this one for the May Connectathon in Montreal
https://github.com/ewoutkramer/fhir-net-api/tree/ft-connectathon-may2016
This is able to be done yourself with a little assistance.
As for generating code for a profile, we haven't done that as yet, but will theoretically be possible.
Don't know that I'd advise this at the moment while the profiles are in so much development and change.
I develop with Visual Studio. I have a class library that contains code common to many products I develop, and is now in use by 15+ solutions. I do LOB apps for my non-software company.
I've been adding this class library project directly to the solutions of all the solutions that need to use it. But I've been using NuGet to pull in many 3rd party packages and I really like its way of doings things. I'm thinking about adding this utility library as a NuGet package in our own repository rather than adding it directly as a project reference in the solution.
Is this a good idea? What criteria should I use to determine when to use NuGet vs when not to for internal class libraries? I realize that some might think this is an opinion based question, but I'm looking for specifically what criteria you'd use to decide rather than opinions about which is better.
Internal libraries that used and worked on by multiple teams can be exposed as Nuget packages. This way, multiple teams can work on the library, and each of them can update to a version as and when needed by that particular team.
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.
I'm attempting to install a Windows Service. I've tried it from within Visual Studio 2010 and also by just double clicking the msi. I followed the walk through here:
http://msdn.microsoft.com/en-us/library/zt39148a.aspx
The problem seems to be an nhibernate mapping exception.
I have a class library with hbm.xml files (yes, they are included as resources) and my entity classes.
I don't understand what I need to do to deploy everything correctly.
A couple of suggestions: First, make sure your project type is a console application. That will ensure that your app.config is seen and renamed/copied correctly. Second, the business of installing and uninstalling (the windows service) is really best done with an open source project called TopShelf. I've personally had great experiences using TopShelf to bootstrap Windows Services. The documentation is a little spartan but there is a simple example to get you up and running quickly. Simply put, it handles all of the messy plumbing to get the service installed and uninstalled by exposing a simple to use command line interface.
I'm involved in developing a sandboxed Microsoft Dynamics CRM 2011 Online plugin and have a set of tests that I can drive from a xUnit front end on my local machine given that I right-click the Package and select the Deploy option (and resort to using the plugin loader sample when that doesn't work).
I'd like to be able to automate the running of my tests on my CI rig, where I'll need it to upload a fresh binary as part of each run.
We've looked at http://pluginregcrm2011.codeplex.com/ but it has bugs that prevent it working for Online and in short looks like it's no longer being maintained and I'm not keen to take ownership of what should be a fundamental tool that a platform/ecosystem should just have.
Is anyone using that tool or another plugin uploader non-interactively? Am I missing something?
I know I'm late with my answer and I`m pretty sure that you already have found a solution which is working for you.
However I felt the same pain and I have hacked a small application which could be used to simply update the plugin assembly, without doing any configuration work.
PluginAssemblyLoader -f "C:\MyPlugin.dll" -c "Url=http://crmserver/org;"
Please see http://msdyncrm-contrib.github.io/PluginAssemblyLoader
There isn't an easy OOB experience with this but the CRM 2011 Developer Toolkit just uses a set of MSBuild targets that you can call yourself. It's just MSBuild, so you could hook it into your CI build if required. If you install or just extract the Developer Toolkit MSI in the SDK you'll find the following two files in there...
Microsoft.CrmdeveloperTools.CrmClient.dll
Microsoft.CrmdeveloperTools.CrmClient.targets
As an aside it would be nice if MS would open source this as the current implementation uses predominantly sealed and internal classes within the custom tasks.