NuGet.Core.dll will depend on the XDT assembly in 2.3

Topics: Ecosystem
Developer
Nov 30, 2012 at 8:48 PM

I'm working on supporting the XDT transformation in NuGet 2.3 (which will not be released until next year). As part of this work, NuGet.Core.dll will have a dependency on the XDT assembly, which is produced by the Microsoft Web Tooling team, for the transformation work.

I don't expect any issue because of this but I just want to make sure this won't affect any partner in the ecosystem.

If you have any concern about this, please raise it here. Let your voice be heard before it's too late. :)

Dec 1, 2012 at 4:19 PM

All in favor :-)

Dec 1, 2012 at 4:58 PM

As long as Microsoft.Web.Xdt can run on Mono, both in terms of not having other dependencies that prevents this and that there is a license form that will allow it, then I see no issues (then again I have no idea what Microsoft.Web.Xdt is). I have to say that I am a bit worries here to be honest. If you head the "The Truth about NuGet and its Future" post http://haacked.com/archive/2012/10/23/the-truth-about-nuget-and-its-future.aspx he is quite clear to point out a couple of things

 - "However, the architecture of NuGet is such that there’s a core assembly,NuGet.Core.dll, that has no specific ties to Visual Studio"
 - "In fact, there’s a NuGet.exe which is a wrapper of NuGet.Core.dll that runs on Mono. Well sometimes it does; and this is where we need your help! So far, Mono support for NuGet.exe has been low priority for the NuGet team. But as I see the growth of Mono, I think this is something we want to improve." (he also points out that Drew Miller is keen to make better Mono support a reality)
 - "On paper, NuGet is a fully independent project of the Outercurve Foundation."
 - "the version of NuGet included in Visual Studio 2012 is officially named the NuGet-Based Microsoft Package Manager and is a Microsoft product"

Again, I want to emphasis that I do not know the specifics of Microsoft.Web.Xdt but from what I spotted, after a quick Google, is that it has something to do with Web.config transformation. 

Microsoft has a strong tradition of not permitting binaries from being deployed on other platforms other than Windows. As an example, the Microsoft.AspNet.Razor package license http://www.microsoft.com/web/webpi/eula/webpages_2_eula_enu.htm states

 -  Distribution Restrictions. You may not 
    distribute Distributable Code to run on a platform other than the Windows platform

However if you used the open sourced source code, and build it yourself, then you are permitted. This leads me to think that Microsoft.Web.Xdt would need to be open-source for anyone to use it on Mono.

The last thing Nuget needs is for Microsoft to create a fracture between the open-source Nuget and the propitiatory Nuget =/ 

Developer
Dec 1, 2012 at 11:15 PM

Good point about supporting Mono. Thanks for brining that up.

Microsoft.Web.Xdt is the component that is doing the config transformation in VS.NET. We'll release a nuget package for it very soon. When that happens, will you mind trying it on Mono and let me know if you encounter any issue on Mono?

Developer
Dec 1, 2012 at 11:17 PM

Wait a minute, how do you know the assembly is called Microsoft.Web.Xdt? I didn't say it in the first post.

Dec 2, 2012 at 12:28 AM

As far as I know Nuget is already on crutches when it comes to Mono. How would one test a VS.NET specific feature library on Mono/MonoDevelop?

When it comes to the name...you ok with chalking it up as "super powers"? That or the Tweet that lead me here https://twitter.com/JeffHandley/status/274905057575723008 ;)

Developer
Dec 2, 2012 at 2:16 PM
Edited Dec 2, 2012 at 2:31 PM

I don't have any experience on Mono/MonoDevelop so I can't answer your question. Perhaps somebody from the community can answer it.

My initial query is to check if we make NuGet.Core.dll depend on the XDT assembly, will it break any existing scenarios on Mono/MonoDevelop with NuGet.Core.dll.

Dec 2, 2012 at 4:43 PM

@dotnetjunky: you seem only to be worried about the technical bits. Xdt may run well in Mono, but even if that's the cose, it's not good that Nuget takes a dependency on a package that is not open source (open source in the OSI terms, which the MS LPL doesn't comply with) because then you could only run it outside Windows "at your own risk".

What license does XDT have?

Dec 2, 2012 at 4:44 PM

typo: s/cose/case/

Dec 2, 2012 at 4:49 PM

If the package will follow the same licensing as the other Microsoft.xxx packages, then having a dependency on Xdt would, form a license point of view, completely make it impossible to run Nuget on any other platform than Windows. The license, like quotes in my first comment, is very assertive when it points this out

 -  Distribution Restrictions. You may not 
    distribute Distributable Code to run on a platform other than the Windows platform

Which can be read in its full at http://www.microsoft.com/web/webpi/eula/webpages_2_eula_enu.htm states

I doubt this would break "any existing Mono/MonoDevelop scenarios", because as stated "Mono support for NuGet.exe has been low priority for the NuGet team". But there are ambitions to build out good support, for instance Drew Miller has mentioned he was interested.


Developer
Dec 2, 2012 at 4:56 PM

You're right. I didn't pay attention to the licensing issue. Thanks for reminding me ;)

For the upcoming release, the Xdt package won't be open source. I'll check with the PM about the licensing issue.

If the license prohibits running on other platforms than Windows, then we'll make this a loose dependency, meaning that you'll get XDT when running on Windows, and no XDT support on other platforms. Does that address your concern?

Dec 2, 2012 at 5:12 PM

@dotnetjunky - for the sake of the discussion, could you explain what Xdt does and how it will be leveraged by nuget.core?

Dec 2, 2012 at 9:43 PM
Edited Dec 2, 2012 at 10:03 PM

If NuGet is trying to encourage an engaging Open .NET community can we try not to make choices that negatively impact its ability to be supported on Mono. I'm hearing Xamarin is looking at integrating NuGet into their IDE - lets not make it hard for them to participate in the ecosystem.

In short, I don't like the direction this takes NuGet. Adding XDT gives Microsoft's version of NuGet a superset of functionality and if it's actually proves useful .NET developers will start relying on it preventing their packages and everything depending on them from running on Mono. NuGet has become .NET's default package manager so I would prefer NuGet to be void of proprietary components entirely, I don't find a loose dependency on closed-source components an acceptable compromise.

Dec 2, 2012 at 10:13 PM

From my point of view, please don't just focus on 'will it break any existing scenarios'

I'm a Windows-first cross-platform dev porting WinPhone/WinRT projects to MonoTouch and MonoDroid, often via PCLs.

We've only recently seen PCL support added to nuget, and we're only just now adding the MonoDroid/MonoTouch/MonoMac folders to nuget - they will be out in 2.3 for the first time.

So I would really hate to see these new Mono opportunities crushed before they even start.

There are plenty of fab things that MS have open sourced (thank you) like Razor. Is there any of these that could be utilised instead of XDT? Or is this part of the functionality just for merging into .config files where XDT is obviously based? If that is the case, then your loose dependency suggestion might work - as long as you document it heavily so that no-one tightens the dependency up in the future.

Thanks for nuget - and for asking about features like this in public so that we can add our opinions.

Stuart

Dec 2, 2012 at 10:18 PM

I believe taking this dependency is a very bad idea due to the platform/licensing issues mentioned above.

Are there any details available which tell us why taking this dependency has been suggested? What problem does the library in question solve? What is the requirement? How about we surface everything to the community and see how the community can help in in providing the required functionality, either by code contributions or otherwise? Should this not be the approach taken by an open source project such as NuGet? Shouldn't taking a dependency like this only ever be an absolute last resort to avoid some kind of show stopper?

Dec 2, 2012 at 10:26 PM

+infinity and beyond for Mono support today and always. please.

Coordinator
Dec 2, 2012 at 10:47 PM

What Microsoft.Web.Xdt brings is the ability for more powerful config transformations. You can find more details here.

Having some dependencies on non-open software isn't the end of the world. After all, NuGet depends on the BCL which is not open source. Naturally, I'd like to see that change, but at least there's already a Mono equivalent for what we depend on there.

The pertinent issue is whether there's already a Mono equivalent to XDT? If so, should we consider using that instead? If not, then taking this dependency on NuGet.core would be a very very bad idea. I shouldn't need to remind you of the shitstorm around MEF when it came out under the Ms-LPL license. That license is just plain horrible.

The best course of action is to convince the owner of the XDT license to simply license it under Apache v2 (since that seems to be the trend with new Microsoft open source offerings) and be done with it. Enlist the help of Scott Hunter if it becomes a problem. He's quite good at leaning on people. :)

Dec 3, 2012 at 4:01 AM

>What Microsoft.Web.Xdt brings is the ability for more powerful config transformations

What are the more powerful config transforms good for, actually? What kind of XML transformations are typically happening in nuget packages, and why do they need to be more powerful?

I'm fairly new to using nuget myself, but in general XML transforms sounds like it might easily lead itself to imperative solutions to problems that work in only in limited circumstances e.g. VS csproj way of doing things, or web project way of doing things, but not in others.

Developer
Dec 3, 2012 at 12:17 PM
Edited Dec 3, 2012 at 12:19 PM

Phil, I've asked Sayed to comment on the licensing.

The reason we want to add XDT support because NuGet users want it. (http://nuget.codeplex.com/workitem/232). In fact, they have been waiting for it for a long time.

I don't know if there's a Mono equivalent to XDT. Somebody familiar with Mono should comment on it. Do people need XDT in Mono as much as in .NET though? Remember you still have the current XML transformation mechanism; it's not going away.

Why I'm saying this is that I don't see a problem if NuGet on Windows is a superset of NuGet on Mono. It's already a case now with support for PowerShell on Windows. I can tweak the implementation such that if in the future a Mono implementation of XDT pops up, it can be easily added alongside NuGet.Core to light up support for XDT. How does that sound?

 

 

Dec 3, 2012 at 1:04 PM

>> I don't know if there's a Mono equivalent to XDT. 

There isn't, this change prevents it from working on Mono.

>> Do people need XDT in Mono as much as in .NET though?

There is no Mono vs .NET type projects or development style - they're the same thing. .NET is designed to be cross-platform, and Mono maintains an Open Source version of the .NET/CLR which realizes this fact. Changes like this causes incompatibilities and are harmful to their mission.

>> Why I'm saying this is that I don't see a problem if NuGet on Windows is a superset of NuGet on Mono.

It is a problem, it makes Mono a second-class citizen. Introducing any superset/incompatibility will put a stigma on Mono's perceived capabilities in the eyes of mainstream .NET developers, leading them to think Mono can't run .NET or that it will be too much effort for them to support Mono so they wont bother trying - this shouldn't be the goal of the NuGet project.

>> It's already a case now with support for PowerShell on Windows.

That doesn't make it right. There is an initiative to fix this: http://pash.sourceforge.net

>> I can tweak the implementation such that if in the future a Mono implementation of XDT pops up, it can be easily added alongside NuGet.Core to light up support for XDT. How does that sound?

It doesn't sound good. If it is important enough to add, it should be important enough to Open Source.

On a side note thanks for bringing this issue to the communities attention, it's great to see the NuGet team requesting feedback from the community. Also I hope this thread starts a change in attitude so incompatibilities like this don't find their way into NuGet, in the future.

Developer
Dec 3, 2012 at 1:22 PM
Edited Dec 3, 2012 at 1:29 PM

>> It is a problem, it makes Mono a second-class citizen. Introducing any superset/incompatibility will put a stigma on Mono's perceived capabilities in the eyes of mainstream .NET developers, leading them to think Mono can't run .NET or that it will be too much effort for them to support Mono so they wont bother trying - this shouldn't be the goal of the NuGet project.

I'm not sure what we can do here. The whole Mono implementation is already a subset of .NET on Windows. There's many things lacking in Mono, not just with this XDT thing. What do you expect us to do? It is not our goal to make NuGet look bad on Mono.

>> It doesn't sound good. If it is important enough to add, it should be important enough to Open Source.

This is another reason why I created this thread: to seek help from the Mono community. We may or many not open source XDT component. I don't know the answer today. If you care about Open Source, consider contributing to it, building an implementation of XDT for Mono. Don't just complain. The fact that NuGet has been working on Mono is thanks to many contributions from the community in the past.

 

Dec 3, 2012 at 1:37 PM
Edited Dec 3, 2012 at 1:49 PM

>> I'm not sure what we can do here.

Seek an Open Source Licence, done.

>> There's many things lacking in Mono, not just with this XDT thing. 

They're lacking because they're created in a closed-source lab and later tied to what should be an Open platform. Of course there wont be an implementation available for Mono, they didn't invent it - if they did it would be Open Source and Microsoft would be free to use it.

>> If you care about Open Source, consider contributing to it

Thanks for the suggestion, you will be happy to know I've already spent many years developing Open Source software and make the extra effort to ensure everything I develop has first-class support for Mono.

>> Don't just complain. The fact that it has been working on Mono is thanks to many contributions from the community in the past.

The solution should not be to let other platforms play cat and mouse while Windows blazes a path without care for keeping compatibility. I'm not sure if there even exists any other platform package managers where features are added at the cost of cross-platform support, I'm not even sure if closed-source package managers are even a thing - I expect this to be a NuGet first.

Dec 3, 2012 at 1:50 PM

>I'm not sure what we can do here. The whole Mono implementation is already a subset of .NET on Windows. There's many things lacking in Mono, not just with this >XDT thing. What do you expect us to do? It is not our goal to make NuGet look bad on Mono.

Ideally you would not take a dependency on something you didn't know would be licensed in such a way that it could run cross-platform. You could actually implement the functionality yourself, at least the subset that people have been requested. That said I understand that this probably would not be in Microsoft interest since you have already invested time and money to create Microsoft.Web.Xdt in the first place

>This is another reason why I created this thread: to seek help from the Mono community. We may or many not open source XDT component. I don't know the
>answer today. If you care about Open Source, consider contributing to it, building an implementation of XDT for Mono. Don't just complain. The fact that NuGet has
>been working on Mono is thanks to many contributions from the community in the past.

There is a bit more too it than that though. On paper, Nuget is an Outercurve Foundation project that is independent of MIcrosoft. You have then created the "Nuget-based Package Manager" (as it is now called in VS2012), which kind of is a fork where you've add proprietary things to support your tooling scenarios. So far nothing strange with that, vendor specific forks aren't uncommon in open-source.

What is a bigger issue is that because you do this, you make sure your fork is made the de-facto standard. This happens because

 a) you are the largest entity that works on Nuget

 b) any attempts to build of the Outercurve Foundation "version" would be futile as long as it's not compatible with the Microsoft flavor - it just won't get any traction unless it is. This is also quite simple, you "control" Nuget.org the features that Microsoft invest in, for their tooling scenarios, find their way to Nuget.org using an express highway.

So the same can be said for Mono. They can base of the open-source version, but they would still have to play catch-up with Microsoft features which is going to be a challenge because nobody is cutting a pay check to work on it full-time.

I am saying that it would be nice to see Microsoft have an outspoken goal for Nuget and cross-platform support. Right now it does seem to be what ever each dev on the team things is important. What I mean by this is that there appear to be a bunch of existing (and former) "Nuget" members that work on features for Mono (such as Daniel Plaisted adding support for mono taget folders), but taking a dependency on something that might be proprietary didn't strike you until it was pointed out.

Inconsistency like this is actually hindering Mono adaption by quite a bit. Why would someone work on Mono support, on their spare time, without getting paid, when there is no outspoken goal of cross-platform support by the Nuget-based package manager? All of a sudden there could turn up a feature that would be a deal-breaker for Mono or at least require a huge amount of work having to be done it make it feature equivalent?

The segmentation IS an issue, like Mythz points out. If the Mono story ends up as "It's just like on Windows, except you can't do X and Y, and when you do Z you also have to do this manual step here and there" then it's simply not going to provide a good enough story for people to use it, even though it would have been a valuable tool to have.

Developer
Dec 3, 2012 at 4:06 PM

>> Seek an Open Source Licence, done.

As I said, I'll ask the owner of XDT component about this option. If it gets approved, then great everyone is happy. If it is not, then we will go ahead with the loose dependency on XDT.

Coordinator
Dec 3, 2012 at 5:59 PM

Thank you everyone for the contributions on this thread - I am glad we can count on all of you to help guide us!

As @dotnetjunky said, we will lobby to get the XDT component's license set up so that it can be used cross-platform.  Does the license need to be open source, or would simply allowing the assembly (and the corresponding NuGet package) to run cross-platform be sufficient?

If we aren't able to secure the licensing needed, we'll take a step back and reevaluate the situation.  As @dotnetjunky pointed out, this feature request has a lot of votes (7th on the list of open items), and it's also been around for over 2 years.  Yes, we worked with the feature team that owns this library to refactor their code to enable the creation of a NuGet package, and yes, the fact this wouldn't work on Mono was an oversight.  My apologies for that, sincerely--it was merely a result of tunnel vision on shortest-path to the feature.

I will also admit that I didn't expect the loose dependency on this to be so controversial.  XDT transforms for web.config seem like an acceptable opt-in type of feature where the package author could also provide a README that explains complex web.config transforms that are needed in order for the package to work.  I recognize how this is viewed as Windows having a superset of the functionality though too.

Once we talk to the XDT team about the licensing, we'll report back and go from there.

Thanks again for the lively discussion and the guidance!

Dec 3, 2012 at 6:00 PM

>> As I said, I'll ask the owner of XDT component about this option. If it gets approved, then great everyone is happy. If it is not, then we will go ahead with the loose dependency on XDT.

Let's all hope Plan A works, because Plan B isn't a shinning example of listening to the community.

"The mission of the Outercurve Foundation is to enable the exchange of code and understanding among software companies and open source communities."
"The Outercurve Foundation projects release intellectual property under a standard open source license."
-- http://www.outercurve.org/About

Honestly I'm surprised it's even an option, as I thought it was contra to the objectives of an Outercurve-run project and had just assumed that everything they did was Open Source, My Bad. 

Dec 3, 2012 at 10:29 PM

Firstly thanks for having this discussion.

Now taking a step back. If certain nuget packages want to use Microsoft.Web.Xdt.dll why cant they ship that with their nuget package and call it from their install.ps1? 

Developer
Dec 3, 2012 at 10:42 PM

If you really decide to use Powershell, it's probably significantly easier to simply manipulate the DOM using it. That said, at this juncture, using Powershell necessarily ties you to VS; not only because it is the only NuGet client that fully supports it, but also because PS authors tend to make assumptions about the presence of VS \ DTE. It would certainly be nice to be able to move away from that. 

Dec 4, 2012 at 12:10 AM

Hi everybody thanks for the comments. I am the owner of XDT. It has always been my intention to open source XDT. I am taking a tiered approach here; release XDT with a redistributable license so that NuGet package authors can leverage it and after that open source it. If we wanted to open source it first it would take more time so I wanted to unblock the main scenario before that.

I didn't read the entire thread but I read most replies, it seems that there the following concerns exist.

  1. Can XDT be re-distributed?
  2. Can XDT be allowed using mono for non-Windows machines?
  3. Will XDT be open sourced?

I just double checked the EULA which we currently have for XDT and below are the answers.

  1. Redistribute, yes you can redistribute XDT with your own applications
  2. Based on the currently EULA Windows machines are a requirement
  3. Work in progress, no promises here but I am personal passionate about this

Regarding #2 I will touch base with our legal team and see if we can lift that requirement before shipping.

Thanks for all your comments, please keep them coming. I am committed to doing the right thing for the community here.

Sayed Ibrahim Hashimi

 

 

 

 

 

Coordinator
Dec 4, 2012 at 7:17 AM

Thanks for following up Sayed!

Removing the Windows only requirement is definitely a good (and for NuGet's sake, a necessary) step. Releasing it under an OSS license is ideal of course, but I know that means you'll be spending a lot of time hanging out with laywers which should qualify you for hazard pay imho. And them too!

This does bring up an interesting question about eventually adding plugin support to NuGet.

There may well be features in the future that are specific to platforms that people will want to layer on to NuGet. Windows isn't the only platform that might want that. For example, imagine transformations that only make sense within Mono on Linux or Mac that could optionally apply to a package. It'd be nice to support layering that on without having NuGet.Core take such dependencies.

Keep in mind that in this particular case, we're talking about a feature that isn't required for NuGet to work. It simply makes some scenarios easier, but there's always the manual option. Much like the case where you have an Install.ps1 but install a package in WebMatrix where the Install.ps1 is ignored.

If we get NuGet running in MonoDevelop, there might be MonoDevelop specific features we want to take advantage of. NuGet.Core should ideally never rely on features that are platform specific. It should all be done in layers above.

Dec 4, 2012 at 7:24 AM

Sayed,

Thanks for the update on this!

Haacked,

I brought this up yesterday in the Nuget Jabbr room as well. I personally don't have any issue with Microsoft shipping an enterprise tool packge for Nuget, or if Nuget takes advantage of features that are platform specific, as long as those aren't in the core themselves. The idea of plugins / extension points was my argument for this as well. Having features "light-up" when available would be a really nice step in the right direction.

Not only that but it would probably make it easier to get features working on both .NET and Mono, because each code base would be a lot smaller and independent of the main Nuget story.

So a big +1 for that =)

Dec 4, 2012 at 8:39 AM
Edited Dec 4, 2012 at 8:42 AM

I just want to echo everyone's sentiment and say thanks a lot for this Sayed, your efforts on this are much appreciated and think this is a great direction for the future of NuGet.

Coordinator
Dec 5, 2012 at 5:42 PM

Yes, thanks @sayed_hashimi!!

I am glad to be making progress on this discussion.  I would love to commit to keeping a Mono build green once we have a good baseline.

With the layering approach though, I feel like we have some conflicting feedback/requirements; I'd like to better understand others' positions on this.

  1. We hear that we should not focus as much energy on Visual Studio integration and that NuGet.Core (and nuget.exe) should have the ability to install/uninstall packages from projects.  This allows better cross-platform usage and prevents packages from using features that only apply to Visual Studio (like PowerShell).  With XDT specifically, as called out above, even though XDT transforms are not a core feature and packages could opt into it much like PowerShell support, it was stated that this would still cause harm to the other platforms.
  2. On the other hand, we hear feedback that there should be a layering approach where "Having features 'light-up' when available would be a really nice step in the right direction."

As @mythz stated above, "I don't find a loose dependency on closed-source components an acceptable compromise."  Isn't that exactly what the layering approach is?  And if we had taken the loose XDT dependency, isn't that the same as well?  I'm not sure how to balance the above two requirements.

Coordinator
Dec 6, 2012 at 7:32 PM

I wanted to send an update that we're leaning toward the open source approach on this, where (assuming XDT can be open-sourced) NuGet will include a submodule for the XDT source and build that assembly as part of the NuGet solution.

I am thinking we should (continue to) defer the XDT feature until we are able to implement it using that approach, so that there isn't a period where nuget.exe cannot be used on Mono while we wait for XDT source to be available.

Opinions on that?

Dec 6, 2012 at 7:34 PM

Sounds good - this approach works for me.

Dec 6, 2012 at 8:58 PM
+1 for waiting till XDT can be open source

However I still don't understand why packages that want XDT can't
simply ship a copy of XDT with their nuget and call it from
install.ps1? Why does that need to be a nuget core feature at all?
Dec 6, 2012 at 10:08 PM
Jeff,

As the person who suggested the "light-up features when they are available" I have now reconsidered and am of the opinion that this would be a very bad approach to take. It was a spur of the moment idea that would be best left undone =)


On Wed, Dec 5, 2012 at 6:42 PM, jeffhandley <notifications@codeplex.com> wrote:

From: jeffhandley

Yes, thanks @sayed_hashimi!!

I am glad to be making progress on this discussion. I would love to commit to keeping a Mono build green once we have a good baseline.

With the layering approach though, I feel like we have some conflicting feedback/requirements; I'd like to better understand others' positions on this.

  1. We hear that we should not focus as much energy on Visual Studio integration and that NuGet.Core (and nuget.exe) should have the ability to install/uninstall packages from projects. This allows better cross-platform usage and prevents packages from using features that only apply to Visual Studio (like PowerShell). With XDT specifically, as called out above, even though XDT transforms are not a core feature and packages could opt into it much like PowerShell support, it was stated that this would still cause harm to the other platforms.
  2. On the other hand, we hear feedback that there should be a layering approach where "Having features 'light-up' when available would be a really nice step in the right direction."

As @mythz stated above, "I don't find a loose dependency on closed-source components an acceptable compromise." Isn't that exactly what the layering approach is? And if we had taken the loose XDT dependency, isn't that the same as well? I'm not sure how to balance the above two requirements.

Read the full discussion online.

To add a post to this discussion, reply to this email (nuget@discussions.codeplex.com)

To start a new discussion for this project, email nuget@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Dec 12, 2012 at 4:59 AM

Hey everyone I wanted to let you know that I have started the process to Open Source XDT. I do anticipate that this process will take some time, especially considering the holidays are starting here. I've never gone through this process myself, so this will be a first for me.

I cannot give you any guarantees or dates, but I will do my best to try and get it out there as soon as possible. If you have any questions let me know.

Thanks,
Sayed Ibrahim Hashimi

Dec 12, 2012 at 5:58 AM

Just in time for a welcomed Xmas gift to the community :)

Thanks again Sayed.

Apr 23, 2013 at 1:57 AM
We have released it under an Apache 2.0 license at https://xdt.codeplex.com/.

Thanks!
Sayed Ibrahim Hashimi
Apr 23, 2013 at 2:46 AM
Great work, thx Sayed.
Apr 23, 2013 at 6:53 AM
sayed_hashimi wrote:
We have released it under an Apache 2.0 license at https://xdt.codeplex.com/.

Thanks!
Sayed Ibrahim Hashimi
Awesome news! Thanks for the hard work and making this happen!