This project is read-only.


Topics: APIs, General
Oct 6, 2014 at 4:50 AM
(CC of a public letter sent to Theo Yaung, also sent to people mentioned in this email.)

Mr. Theo Yaung,

The open source aspect of the Roslyn project has been in a complete disarray for more than 3 months now; less than 3 months after its public announce.

As stated by a few people on Roslyn's Codeplex site, your instructions for "Building,
Testing, and Debugging" Roslyn are - on almost every single level and aspect - disconnected from reality. No one from Microsoft replied to the members caring enough to let your group know. No one from Microsoft attempted to fix - or publicly address - this issue. What could be possibly more fundamental to an open source project that its community being able to compile, test and debug the code?

Sir, it has been more than 3 MONTHS that your group is misleading people into trying to setup and work with the Roslyn sources. We personally invested more than 30 hours of our time trying to hack our way into making it work for us, and for the rest of the nascent Roslyn community. Perhaps some on your team brushed off those other members complains as being coming from a minority of inept programmers. Well, if that's the case, they were wrong: no amount of reinterpretation, correction and hack is able to make your instructions to work. Note that I refer as those instructions as been yours since you're the last one to have updated them in July; from the instructions for pre-14 VS versions to the v14 one.

In the open source world, that kind of management are to be expected from small groups of amateurs, yet - and pardon me to say it - even these kind of group rarely display that kind of ineptitude and lack of consideration for the community. This is Microsoft. This is the future of their .NET Compiler. This is Microsoft's boldest open source move. This is now in disgrace for more than 3 months, and has fallen into such state less than 3 months after Microsoft announcement at Build 2014!

I'm sending a copy of this letter to a few interested people, including MSFT
developers/partners PR, Anders Hejlsberg, Satya Nadella, the Microsoft Open Source group and the Xamarin people. At your demand, I will forward them your reply to our group's letter.

Please let us know how and when the open aspects of the Roslyn project will get back on track for those of us who accepted Microsoft's invitation to contribute to this project.

7 developers waiting to work full time on enriching VS and .NET ecosystem through Roslyn, after accepting Mr.Hejlsberg invitation.
Oct 6, 2014 at 7:54 AM
Edited Oct 6, 2014 at 8:08 AM
I've had no issues compiling and using the roslyn sources, I'm compiling Roslyn in VS 2012 and VS 2013 with only minor adjustments in the project files. Maybe if you explain what problems you have someone can help you? (Or a link to the thread if you explained it before.)

(You are however correct that the responsiveness of the team is pretty bad, I guess they underestimated the amount of work open sourcing the project would take.)
Oct 6, 2014 at 9:16 AM
Hi, Scynapse,
Yep, we've been a bit quiet (as Zarat notes), and my apologies for that. We are (finally) in the final stages of locking down the APIs for this first version of Roslyn, and so have been nose to the grindstone on that. In fact, I'm pleased to report that, at 8:34PM Saturday evening, we actually hit zero bugs (what we call our ZBB, or "zero bug bounce", which basically means that all bugs older than 72 business hours have been dealt with). We'll probably bounce up a bit from that, but the goal for us is to actually shut down on APIs (modulo any feedback coming from you folks on them, which we'd have to fix before actually shipping) this month so that people (including other folks in VS) can take a bet on those APIs and expect things to remain relatively stable. The first thing I have scheduled after that lockdown is a reassessment of the current OSS infrastructure (things like Codeplex vs. GitHub, adding more automation to catch failures in the infrastructure earlier, and so on) -- in fact my leads and I have a kick-off meeting on this later today. (You should also start to see more devs coming up for air as well.)

Can you clarify specifically what the issue is in the case that you are encountering? I'm sure that it's been brought up in other discussion areas, but it would be useful to have it all brought together (or you can send me mail at Based on the page that you reference in your text as well as other clues in there, I'm worried that this might be about loading & debugging your version of Roslyn into the VS IDE itself (i.e., so that you can see how your changes affect the IDE and debug them). If that's the case, then that is indeed a convoluted process which is currently beyond our ability to streamline any more than it is. I can see how a person might in fact refer to it as "disconnected from reality," and to be honest, in my darker moments, I've sometimes felt that we should have just said "not supported" and left it at that given all of the gymnastics that are required to use it -- but we thought some brave souls might want to give it a try, and so there it is. The overall problem has to do with two issues: constant API change which breaks the corresponding closed code, and also the fact that VS requires assemblies to be strong-name signed using our private key. (I can go more into details if you like.) As noted above, the constant API change will at least be winding down, leading to an island of tranquility at some point until we start defining a vision for the next version.

If that's not the issue and I've completely misunderstood, then please let me know, and we will track this down. It's definitely the case that we haven't had the ability to leap in as much as we'd like, and it wouldn't surprise me if, combined with our newness to the process, we'd missed something obvious. However, for general usage, we haven't received any recent reports of build & run being problematic on the command line, so if there is one, we'd definitely jump on it.

Matt Gertz
Dev Manager, Roslyn
Oct 6, 2014 at 3:43 PM
One clarification -- by hitting ZBB bugs, I mean bugs required to be fixed for the next Preview & also to lock down APIs, not all bugs associated with Roslyn overall. (That's what I get for typing up responses in the wee hours of the morning...)
Oct 6, 2014 at 7:10 PM
Matt Gertz!

Thank you for answering our call. I'll give you the details as soon as I can get my hand on a physical keyboard.

Meanwhile, to clarify the problem, the Building, Testing, and Debugging instructions is simply broken, both in terms of execution and outcomes. My understanding is that before Theo Yaung updated those instruction, in July, those were apparently working fine. The issues arise when you try those new instructions for VS 14 CTP. If you setup a fresh Win8.x VM clone and apply the current instructions by the letter, you'll get error messages at 2 different steps and you won't be able to compile Roslyn. Then if you debug manually the prepare script (e.g. wrong SDK targetting, msbuild prepare not executing because the path isn't quoted) and then if you fix the toolset version to one able to actually compile Roslyn (releases/build-preview), THEN you have you first real shot at compiling correctly Roslyn (releases/build-preview). However, the change you make to the source doesn't translate to the rooted VS, no matter how you do it, starting with following the actual instructions.
that is indeed a convoluted process which is currently beyond our ability to streamline any more than it is.
And is the misunderstanding: It is not a convoluted process lacking streamlining; it is simply not working at all. Hacking through scripts and config apparently got a few of us using the current instructions to compile correctly, but even us can't test and debug in VS, after all that. It isn't convoluted. It doesn't work as specified in the instructions and it doesn't result in outcomes specified in the instructions. This is the bootstrapping process to this nascent community - very fundamental to an open source project - and the strap as snapped 3 months ago.
I can see how a person might in fact refer to it as "disconnected from reality,"
Open up the scripts. Check the toolset versionning. Run the test on a free VM clone and you'll see that this disconnection from reality is directly observable in the code/config. You'll be then forced to concluded that this disconnection can only arisen from the fact that no one on your team have properly tested those instructions before publishing them. From then on, this disconnection survived until now because no one on your team investigated the (well-detailled) complains members made in the general topic or issue sections. I'll send you the links to those reports as soon as I get my hands on something better than a smart phone. Sorry about that.
and to be honest, in my darker moments, I've sometimes felt that we should have just said "not supported" and left it at that given all of the gymnastics that are required to use it -- but we thought some brave souls might want to give it a try, and so there it is.
Brave souls have indeed gave it a try and gone further than the new instructions could, then shared with your team - and others - their discoveries and limited results. Gymnastics isn't the problem here. It's the gymnastic routine that is the problem. Give us 4 times more instructions and have us edit executable with hexadecimal editors, do the moonwalk, and what not if you must, we'll do it! We're not getting lost in the instructions. You didn't test those and no where in the instructions is it told; told that "It may have a chance at working, but it's just a guess for those who would like to see how far they can go with them".
I've sometimes felt that we should have just said "not supported"
If you mean "not supported" as in "at your own risk and peril", then I disagree. If you mean it as in "As of July 2014 and until further notice, no VS 14 integration is possible; or at least we can't tell you how to try." then yes, I agree since it reflects the fact of the matter is that those new instructions never lead anyone to successfully do what it promise, including internally in your team. Also, alternatively, you could have stuck with one code version of Roslyn and the instructions that had it to work in VS 2010/12(?), like it was before July 2013, so that new comers could get their hand at least into something they could actually build, test and debug. Even the instructions states that the master branch isn't viable for external members anyway, so it's not like external members absolutely need to be on the edge of Roslyn development, as they couldn't anyway.
The overall problem has to do with two issues: constant API change which breaks the corresponding closed code, and also the fact that VS requires assemblies to be strong-name signed using our private key.
I understand this, but is that the real problem? To me the current fundamental problem of this open source project is that newcomers don't have a proper set of instruction to set themselves properly into the latest "non-API-incompatible version of the Roslyn code version that actually work with VS 14". Give us a branch that as a version compatible with VS 14 CTP 3 and proper (tested) instructions to set this up with VS 14 CTP 3, and the open source aspect of Roslyn is back on track. Let us know that this was old work, but that an improved API-stable-and-fully-VS14-integrated Roslyn preview is coming, but that meanwhile we at least can fully play with the latest VS14 CTP 3-compatible branch. You investigate and their actually never had a version or Roslyn that was really VS14 CTP-(API)compatible? Then, (at last resort?...), let's fall back to the code version was API compatible with an older VS version... with proper intructions.

Am I missing something here Matt? I recon having lost many sleep hours on trying to make (releases/build-preview) to work with VS14. Coffee goes so far and I feel I may missing something obvious.

Thanks again Matt! Getting some of that Roslyn excitement back since you replied. :)
I'll wait for your reply, but I'll make sure to let people (reddit/twitter/other channels) know that the team is willing to work this out.

(note: It is possible that systems having in the past followed the old instructions actually do somehow okay when applying the new VS 14 one. For that reason, a fresh Win8.x VM clone seems the proper test for the actual instructions.)
Oct 6, 2014 at 9:09 PM
Just a quick note, Scynapse: we just discussed this at our aforementioned infrastructure meeting. We know what most of the problem is (a script that didn't get updated, which we missed doing because we use a build where VS is always in step with Roslyn and thus doesn't have this issue) and we'll be working on that. I would like to put you in contact with the dev so that you can test his changes and confirm that the changes will work for you. Can you send e-mail to with whatever e-mail address you'd prefer to use for this? I will make introductions and get this going. Once we've got that cleared up, we can then verify that the rest of your scenario works.
Oct 6, 2014 at 11:36 PM
Hi Scynapse,

My name is Kevin Ransom, I work for the Managed Languages Compiler Team at Microsoft. You will often find me lurking around the Visual F# Tools open source project also here on CodePlex. Somewhere along the way in the migration from primarily VS 2013 development to primarily VS 2014 development we took our eye off the ball and the 2014 build environment failed to keep pace - which seems counter-intuitive but is what happened. It is absolutely our intent that Roslyn is a fully collaborative open source project.

My MS email alias is kevinr feel free to email me your detailed concerns – please work with me to ensure that using VS 2014 CTP for Roslyn Open Source development is a better than it is now.

Oct 8, 2014 at 12:41 AM
Thanks Matt. I'm very appreciative. I will write you in the next hours.

Hi Kevin, I'm looking forward to help you in every way that I can and on every aspect you'll judge pertinent. As much as I'd like to begin doing that right away, I'll be unavailable until friday for medical reasons. I'm contacting you before the end of the week.
Oct 8, 2014 at 2:08 AM
My friend,
we are going to be besties :-) and in the process I will do my utmost to convert you to F# ... because as everyone around me knows I am a bit of a monomaniac on that :-)

If you think you will be able to contribute code and updates I would urge you to take this time to fill in a Contribution License Agreement, the link is here:

Here is what I know so far:
  • the Roslyn Solution build issue is due to a bug elsewhere in Visual Studio, that was introduced a long time after Theo's instructions were published, the bug was fixed on the 17th September, but the fix has not yet propagated to the CTP preview branch. I'm not sure if this is irony but I also saw the same bug building F# portable libraries so I immediately recognized the issue as soon as I saw it building OSS roslyn. I have a work around that is easy and we will check in shortly. hopefully tomorrow or the next day --- sorry nothing is ever speedy.
  • The next issue to work on is debugging Roslyn binaries from within VS using the roslyn hive. The mechanism that we built for VS 2013 worked because the Roslyn VS 2013 preview was installed as a VSIX. Now that Roslyn is firmly integrated into VS and the old native compilers are gone we can no longer do the same trick. That it didn't get updates is entirely my fault ... I have been focused on F# pretty much since Roslyn open sourced and as such I didn't notice that Roslyn was now going out with VS 2014 and the old mechanism would no longer work. Still I have a pretty straightforward plan, and expect it to work pretty well. Hopefully we'll be able to test it out in the next couple of days, and then we can move on to knocking off some of the hard problems :-)
Anyway ... send me an email and please consider doing the CLA thing, because contributing is pretty cool, and very useful.


Oct 8, 2014 at 3:21 AM
(I'll just add that, while I appreciate Kevin's attempt to fall on his sword, in fact the real culprit here is that we (as a team, not any one individual) didn't have automation covering this particular scenario and should have. Our new infrastructure drive for OSS has the goal of strengthening all of that -- and of course we'll be fixing this particular issue right now. OSS is a relatively new experience for us, and we're learning more all the time. Thanks to the community for sticking with us, and keep the feedback coming!)
Oct 10, 2014 at 10:54 PM
Edited Oct 10, 2014 at 10:55 PM
KevinRansom wrote:
If you think you will be able to contribute code and updates I would urge you to take this time to fill in a Contribution License Agreement, the link is here:
If I could jump in here:

It remains extremely difficult to contribute to Roslyn as you guys are using an internal bug tracker and the team is very silent on Roslyn's Issue's page. Even Eric Lippert's extensive and detailed bug reports have gone unacknowledged. I think there has been only one post from a Microsoft team member within Roslyn's Issues in the last two months.

This means when a bug is reported on Roslyn's issues, we have no way of knowing whether:

A. It's really a bug.
B. It's been fixed on an internal branch.

It would be really great if you guys could either open your internal bug tracker, or participate more frequently within Roslyn's Issues page. Even something as simple as "We've reproduced this and are tracking it internally" would be more helpful than complete silence.
Oct 10, 2014 at 11:35 PM
Thanks for the feedback, Josh. Yes, we are in a weird situation where we have to straddle both the closed and open world, at least for now, and this creates additional moving parts and barriers that we'd rather not have to deal with (believe me...) Bug tracking is one of those. The infrastructure work that I note above will go some way towards specifically addressing that problem.

However, it's likely that there will always be some separation on bugs. Some reasons may be obvious -- for example, security issues where we want to do research and ideally have a zero-day fix before announcing to the world that we left the front door open with all of the valuables inside (though I recognize that there are two sides to that argument). Some reasons are a little more subtle: VS and other Microsoft products have asks on us that deal with closed technology that cannot be announced publically yet: "Compiler team, please consider altering this API to support this world-changing, internally confidential idea that we just came up with yesterday." We stand in the middle of all of this, and so we need to figure out how we deal with those airlocks.

We do have a bug pump that goes back and forth, so if you haven't heard back on the bug, then it hasn't been resolved yet. In the past two months, we've been dealing with API shutdown almost exclusively -- those bugs have the priority -- and thus resolution on other issues decreases. But one issue here is the response back to CodePlex is triggered by a resolution, not intermediate markup on the bug, so that while we may in fact be working on an issue, you won't see that until we resolve it. We didn't initially think it was going to be as problematic as it is (being naïve, perhaps) so long as we moved bugs through at a good pace, but it becomes a very visible problem in case where we are going dark on other bugs. There are good reasons for the current setup to be in place -- other folks in closed-code land accidentally adding inappropriate info to the bug, for example, which is not too far-fetched of a scenario -- but I'll take this as an action item to see if we can at least create some sort of update whenever text is added to the bug, so as to indicate investigation exactly as you suggest above.

And, as alluded to elsewhere, I really do want our team to be more active on the Issues page and other pages and am pushing for that now.

Oct 11, 2014 at 12:17 AM
Thanks for the reply Matt.

I completely understand that you guys are kind of in a tough space, balancing both open and closed source components. I also realize you can't always add sensitive information to the issues within Roslyn.

Perhaps just updating the "Status" on a bug to "Active" instead of "Proposed" would signal to the community that someone is looking after it.

Oct 11, 2014 at 5:37 AM
Sounds like a good idea to me. Just to set expectations: infrastructure planning is happening this sprint, and we plan to start implementing changes in the following sprint (November timeframe), so it won't quite be instantaneous and may go a couple of sprints depending on how much work we decide to do -- but I do want us to get it right & get it done in one fell swoop, rather than drag it out. Rather than hijack this thread, which I want to use for driving the scripting issue, I'll start a discussion thread when we begin the other work, to keep everyone up-to-date on progress we are making.
Oct 11, 2014 at 11:02 PM
Sounds good.

I realize you guys are probably under the gun right now, so this might be an issue best revisited after Visual Studio "14" officially releases.

Thanks again for all your hard work and for opening this stuff up in the first place. :)

Oct 12, 2014 at 6:15 AM
Edited Oct 12, 2014 at 7:13 PM

Hi mate I'm sorry it's taken so long to get back to you, but it's taken a while to work through things.

So ... I have made a fork that we can work with, and checked in a fix that builds and allows debugging under CTP 4. The work flow to use it is pretty simple:

1: Install VS2014CTP4 and VSSDK for VS2014CTP from Visual Studio "14" CTP 4
2: Set a global environment variable called OpenSourceDebug=true
3: Install the Git tools for windows from Git tools
4: In an administrator VS2014 command window enter the command:
   *  git clone
   *  git checkout remotes/origin/releases/Dev14CTP4
5: execute the batch file that creates a vs hive called Roslyn and prepares a vsix component:
  *  enableossdebugging\src\Tools\Microsoft.CodeAnalysis.Toolset.Open\Scripts\Prepare.bat
6: build Roslyn
  *  MSBuild enableossdebugging\src\Roslyn.sln
7: execute VS in the Roslyn hive
  *  "%devenvdir%\devenv.exe" /rootSuffix Roslyn
8: Start a VS in the default hive and attach it to the vs started earlier set a breakpoint at the point you want to debug.
  *  "%devenvdir%\devenv.exe"
Remaining Issues to think about solutions for:
A: This only enables debugging of VS hosted components, compiler and compiler server are not integrated into VS.
B: prepare.bat requires administrator mode because of use of sn -Vr to disable strong name verification, I was talking with some folks who have suggested a super cunning solution to this ... I think we should give it a try ... because it's super cunning and therefore fun.
C: Do something to make tests runnable

Let me know what you think? what works, what doesn't? what we should change?


Oct 14, 2014 at 6:20 AM
Edited Oct 14, 2014 at 6:24 AM
My friend, we are going to be besties :-) and in the process I will do my utmost to convert you to F# ...
because as everyone around me knows I am a bit of a monomaniac on >that :-)
I can already tell we will Kevin. Also, consider me interested in F#. I was planning on picking a multi-paradigm functional language for some time now. I had Nemerle in mind at some point, but for multiple reasons I’ll probably go with F#. My reaction to you being on team-F# was “F#?! Niiiiice”, so you know very little evangelism should be required from you to get me into it. :-)
If you think you will be able to contribute code and updates I would urge you to take this time to fill in
a Contribution License Agreement, the link is here:
I will review the license and I expect to move that out of the way in the next 2 days.
sorry nothing is ever speedy.
So far you’ve been much faster than me and I apologize for that. For reasons out of my control, my interactions with you won’t get much speed until a few weeks. I’m speaking about knocking off hard problems; you can count on me to help you with the Roslyn<->VS14 problems in the coming days.
So ... I have made a fork that we can work with, and checked in a fix that builds and allows debugging under CTP 4.
That’s great Kevin! I’ll follow your instructions and let you know how it goes.
Remaining Issues to think about solutions for:
A: This only enables debugging of VS hosted components, compiler and compiler server are not >integrated into VS.
Do you see a way to make the compiler integration working again before the next preview release? Speaking of which, is there a known timeframe for this release? If the release is imminent (say in the next 10 days), putting considerable efforts into fixing this issue may not be worth it. Now, if it’s due in 3 months, that’s another story. Compiler integration and debugging is my top concern. I should have made that clear before, but I actively avoided highlighting my specific needs to address the big picture from the community’s perspective.
B: prepare.bat requires administrator mode because of use of sn -Vr to disable strong name
verification, I was talking with some folks who have suggested a super cunning solution to this ... I think >we should give it a try ... because it's super cunning and
therefore fun.
Yes, I see how this could be an issue for some. What have you in mind? :-) Also, a member pointed out that batch file was considered a bad practice and that .cmd would be more appropriate from good practices point of view. I don’t have an opinion about this and see .bat as being just fine for the job. I’m just reporting another member’s take on it, for your consideration.
C: Do something to make tests runnable
Indeed, but as long as you (MSFT) can run those tests internally on the latest versions, you see me less preoccupied by this issue. :-P
I feel the importance of this issue positively correlates with how much longer we are from the next preview release date. I have yet to look into the test issues, so I have no idea how big of a challenge it could be. Do you? I’ll look into it.
Let me know what you think?
I think things are getting back on track. And I think you guys response to my calling is absolutely great. Considering the tone I made use in my open letter, I’m especially impressed. Speaking of which, I want you and Matt to know that the intensity of my letter - and the blames it contained – wasn’t (and this is extremely counterintuitive) targeted to MSTF developers. Between the top-level management’s development of strategies and their real-world implementation by developers, there are sometime managers who become multifactorially pressured into managing resources in ways which end up to be unfair to the original essence of the business strategy and, sometimes… to reality itself. When this happens, one does not simply address internally those special kind of disconnections (strat<-/->dev) with the mid-management: Devs rarely hate their jobs enough to put their nose into the top-bottom big pictures… while the high-level management simply aren’t aware of the operational disconnections impeding the success of their strategies. While top-bottom and bottom-top processes usually catch-up those disconnections, they sometimes simply fail.

I thought this could be such a case here - as I couldn't explain the situation differently - and figured an external actor could give the original strategy a chance to reconnect all the way down with its implementation, by pointing out to the strategy authors the hurdles their implementers (the devs) were experiencing. This was a complete shot in the dark and for all I know my theory was utterly wrong, but I know as a fact that Scott Guthrie cared enough to add Julia Liuson & Soma Somasegar in the loop, saying “Let’s get this fixed ASAP.”

Did you guys gained a little more resources? I hope, but I doubt. Was my theory right? It doesn’t matter. What do matter though is that Microsoft care enough about their OSS projects for 3 of their VP to pay attention to the plea of a few of its project’s contributor, and then act upon it. From an unknown external developer to the top execs of the 3rd most important company in the world (Market Cap), to the internal developer team and back to the community, in less than 19 hours.

So good, it’s downright inspiring.

@Matt @Kevin
If you think Scott, Julia and Soma would be comfortable with it, I think it would be fair to share this positive part of the story on the forums I posted my open letter.

@Kevin, for one-to-one work, are you okay with emails? Or do you prefer all of our exchanges in this thread?
Oct 14, 2014 at 7:28 AM

you should share what you feel comfortable sharing. We share the same goals we all want to make Roslyn a productive open source project, thank you for pointing out that we dropped the ball, because we absolutely did. Our job now is to fix the things that get in the way of Roslyn being a productive open source project for it's contributors.

As for .bat files, I'm not sure why a .cmd file is a better practice than a .bat file, I usually name them .bat because I have been working with dos and windows for longer than I care to admit. The issue I was referring to was that sn -Vr requires administrator privilege to update the registry with skip verification entries. So on Friday I was chatting with a couple of my mates on the BCL team and they suggested something they had been batting around but hadn't tried out yet.
So the theory goes like this :
  • If you delay sign an assembly and then flip the signed bit in the PE header the runtime will be able to load the assembly as if it was fully signed without requiring the skip verification registry entries.
  • The assembly is not verifiable, can't be loaded into the GAC or run in partial trust code, but it can run from a local hard-disk In a full trust application under DOS 4.0 or higher.
Over the weekend I knocked up a little utility to perform this little trick and have successfully run Roslyn built from the open source code base, with this 'Fake signing' and no skip verification entries in the registry. So we will be able to remove the skip verification from prepare.bat, which is neat. It needs tidying up, and adding to the Roslyn build

We should be able to easily integrate the open source build compilers, and it should be independent of the CTP builds so we will just keep updating the open source codebase.

Anyway, let me know how you find the debugging branch, I will work on integrating this Fake Signing trick.

Oct 14, 2014 at 3:39 PM
Couldn't say it any better than Kevin -- we're new at it this and motivated to get it right. And no worries about manager pressures and whatnot -- I've got good ones who are similarly motivated (and I'm not saying that just because they may be reading this ;-)) If you are dissatisfied, or become satisfied, of course we and they would like to hear all about it.

Oct 15, 2014 at 11:34 AM

Happy Thursday,

I have updated my fork with a tool to do the fake signing and updated the Roslyn build to fakesign built assemblies.
  • set a global environment variable :
  • set opensourcedebug=true
  • git clone
  • cd enableossdebugging
  • git checkout fakesign
  • Src\Tools\Microsoft.CodeAnalysis.Toolset.Open\Scripts\Prepare.bat
  • Ensure that none of the Roslyn binaries have skip verification
  • sn -Vu Microsoft.CodeAnalysis.CSharp.Desktop,31BF3856AD364E35"
  • sn -Vu Microsoft.CodeAnalysis.CSharp,31BF3856AD364E35"
  • sn -Vu Microsoft.CodeAnalysis.CSharp.FxCopAnalyzers,31BF3856AD364E35"
  • sn -Vu Microsoft.CodeAnalysis.CSharp.Workspaces,31BF3856AD364E35"
  • sn -Vu Microsoft.CodeAnalysis.Desktop,31BF3856AD364E35"
  • sn -Vu Microsoft.CodeAnalysis,31BF3856AD364E35"
  • sn -Vu Microsoft.CodeAnalysis.FxCopAnalyzers,31BF3856AD364E35"
  • sn -Vu Microsoft.CodeAnalysis.VisualBasic.Desktop,31BF3856AD364E35"
  • sn -Vu Microsoft.CodeAnalysis.CSharp.Workspaces,31BF3856AD364E35"
  • sn -Vu Microsoft.CodeAnalysis.VisualBasic.FxCopAnalyzers,31BF3856AD364E35"
  • sn -Vu Microsoft.CodeAnalysis.VisualBasic.Workspaces,31BF3856AD364E35"
  • sn -Vu Microsoft.CodeAnalysis.Workspaces,31BF3856AD364E35"
  • sn -Vu Roslyn.SyntaxVisualizer.Control,31BF3856AD364E35"
  • sn -Vu Roslyn.SyntaxVisualizer.DgmlHelper,31BF3856AD364E35"
  • sn -Vu FxCopRulesSetup,31BF3856AD364E35"
  • sn -Vu Roslyn.Compilers.BuildTasks,31BF3856AD364E35"
  • sn -Vu csc,31BF3856AD364E35"
  • sn -Vu vbc,31BF3856AD364E35"
  • sn -Vu VBCSCompiler,31BF3856AD364E35"
  • Load Roslyn.sln
  • download any missing nugget packages
  • build Roslyn
  • run a new instance of devenv using:
  • devenv /rootSuffix Roslyn
  • Attach a debugger to the version of devenv started above.
Let me know how you find this

Oct 16, 2014 at 7:10 AM
Edited Oct 16, 2014 at 7:13 AM


I'm having issues compiling BasicWorkspace.
Line 601 of VisualBasicProjectFileLoader.vb

"#If Not MSBUILD12 Then
            Public Function SetAdditionalFiles(additionalFiles() As MSB.Framework.ITaskItem) As Boolean Implements MSB.Tasks.Hosting.IAnalyzerHostObject.SetAdditionalFiles"
No method SetAdditionalFiles is found for this interface.
Toolset issues? Outdated version of VS14 (CTP 3)?

FakeSign was crashing often because of the missing .dll (since I can't compile all the way), so I've added a File.Exists check in the main.

The prepare.bat has problems with paths having spaces in their names. e.g. "C:\Local Workspace\Roslyn\".
Quotes around the paths (e.g. %~dp0) should fix this, but I haven't tested yet.

When I'll feel confident about those changes, I'll send you a pull request. :-)
Oct 16, 2014 at 7:14 AM
Nice work.
Oct 16, 2014 at 8:52 AM
I have been thinking that now that we have fakesign, and there is no need to have a one-off admin step to set skip verification, We can move the prepare.bat functionality into a project file somehow. We would also need a startup project with a debug command that starts VS in the Roslyn hive. Then we would be in the excellent position of having the instructions be:
  1. Clone the open source repo
  2. Start VS, open src\Roslyn.sln
  3. Press F5
I think if we can get to that, then we will be golden. At least on build and debug. There will still be plenty of stuff to improve, but the main workflow will be pretty excellent.

What do you think?

Oct 16, 2014 at 7:50 PM
Edited Oct 17, 2014 at 6:27 PM
As for the build issue, we are working with the VS14 CTP4 Roslyn branch.

One of our difficulties is that Roslyn and VS14 are being co-developed, a consequence of that is that some of our most significant dependencies change underneath us and so they change underneath us from time to time. I have been working with CTP4 and it seems to be build fine for me and so ...I would suggest that you install the preview of VS14CTP4 and the corresponding VSSDK from here:


Oct 17, 2014 at 12:28 AM

As the original instructions were referring to CTP3 around Oct the 5th, I missed the fact that CTP4 was out. I apparently didn't read your instructions as good as I thought I did. Sorry about that. I'm installing CTP4 and its corresponding VSSDK.

Good work Kevin and thanks.

I strongly agree with your approach to make Roslyn OSS great.
Clone the open source repo
Start VS, open src\Roslyn.sln
Press F5
Doesn't get better than this. I'm setting myself up and I'll look into porting the .bat to C#.
Oct 17, 2014 at 12:46 AM
I was actually thinking of replacing the batch file with a project file that did the magic on clean. Although the dance may be a tad tricky.

Oct 20, 2014 at 10:35 AM

Help Wanted

I have created a fork, which has the necessary code to support build and debugging Roslyn. Please review, Test and Comment on the code I particularly am interested in if you can break it.
  1. You will need to Instal Visual Studio 14 CTP4 from here
  2. You should also install the Visual Studio 14 CTP4 VSSDK from the same page
  3. Clone the repo using: git clone
  4. Checkout the CTP4 branch using: git checkout releases/Dev14CTP4
  5. Start VS, Load the Roslyn Solution
    6: Set the Tools\OpenSourceDebug to be the default project
  6. Press F5 to start debugging
  7. The solution will build and start a new instance of Visual Studio
  8. In the new instance of VS create a new C# or VB project
  9. In the VS with the Roslyn solution open, add a breakpoint to the file: Workspaces\workspace\workspace.cs at line 142
  10. add an interface to the project created earlier and see the breakpoint hit.

Here is a very dull video of the process
Oct 21, 2014 at 1:46 AM
Help incoming. I'm retesting tonight. Last time I was able to compile correctly but didn't had the time to test further. For some reasons I thought I let you know that, but didn't.
Oct 21, 2014 at 2:37 AM

It works perfectly. This couldn't be more streamlined than this.
Great work Kevin!

Can I help with you anything else for the moment?
Oct 21, 2014 at 3:28 AM
Thanks, for looking at it. I'm going to try to add compiler integration, so that could do with a look at, when I have it.


Oct 22, 2014 at 6:59 AM

Help Wanted to Test Compilers Wired Up

I have wired up the OSS built compilers to visual studio, so now you can add keywords, and use VS to build projects using those new keywords.
1.You will need to Instal Visual Studio 14 CTP4 from  here 
2.You should also install the Visual Studio 14 CTP4 VSSDK from the same page 
3.Clone the repo using: git clone 
4.Checkout the CTP4 branch using: git checkout releases/Dev14CTP4 
5.Start VS, Load the Roslyn Solution 
6. Set the Tools\OpenSourceDebug to be the default project 
7.Press F5 to start a new instance of VS
8.Create a new C# or VB project
9. Use Tools/Options/Projects and Solutions/Build and Run to set the 'Build Project Verbosity' to 'Normal' so that we can ensure the correct compiler was used
10. Build the solution you built in Step 8.
11. Look in the Build Output Window and observe the compiler used is similar to:
To compile from the command line using msbuild do the following:
1. In a Visual Studio Command Shell, type the following command:
2. __set RoslynHive=VisualStudio\14.0Roslyn
3. msbuild ConsoleApplication01.csproj /t:Rebuild
4. In the build output from this command observe a compiler command line similar to:


Oct 23, 2014 at 5:47 AM
@KevinRansom Great. I'll be getting on it in the next 48 hours.
Oct 23, 2014 at 9:22 AM
thanks mate
Oct 24, 2014 at 8:58 PM

I won't be able to get on it today as I hoped I could do.
I cleared my whole weekend so I could dive into it as much as I want to, (so the whole weekend).
Oct 27, 2014 at 5:23 AM

It works for me! I'll test a few scenarios in the coming days and let you know if I find anything of interest.

Thanks for all your work Kevin! Awesome job!
Oct 28, 2014 at 8:23 PM
Edited Oct 29, 2014 at 2:50 PM
The last thing missing is that somebody goes to and makes a link to this discussion :)
Oct 29, 2014 at 1:19 AM

I'd prefer the members to be spared this drama-spawn thread. I guess Kevin - or someone else from MSFT - will update the page with the new instructions rather than link to this thread.

Olmo, have you tried the new instruction in this thread? and, if so, did everything worked as intended?
Oct 29, 2014 at 1:22 PM
(And we will definitely update the documentation as soon as it looks like we're all good here. Probably could go anytime now, but I'll leave that up to Kevin to make the call. --Matt--*)
Oct 29, 2014 at 4:08 PM
I got it working yesterday at the beginning, definitely it compiles while the official instructions do not.

But now VS 14 crashes like crazy just after opening a simple console project.

I tried executing the prepare.bat -u (since the new instructions don't require it) and uninstalling xunit runner with no luck.

Sometimes it takes a few actions but most of the times just when creating/opening/compiling any project vs crashes. I'll try to repair installation, it there's any information I can send you just tell me.
Oct 29, 2014 at 5:41 PM
Edited Oct 29, 2014 at 9:45 PM
Hi Olmo,

I have done a first draft of updating the instructions, currently no one other than me has reviewed them. Since the feature is not checked in I will not be wiring them up until it is. You can review them here:

As for the crashing:
  1. Did you install VS 2015 CTP4? You can check by doing Help/About It should say:
    Microsft Visual Studio Proffesional 2015 Preview
    Version 14.0.22129.1.DP
    (C) Microsoft ....
Rosl;yn is being co-developed with Visual Studio 2015 and so many of the dependencies API surface are change on a daily basis, these API changes can cause crashes. So to make that workable we have a separate branch in git for each CTP, with the source code frozen to the release that matched the CTP ... e.g. releases/Dev14CTP4

To help diagnose the crashes:
there is a log file created when VS initializes at: %USERPROFILE%\AppData\Roaming\Microsoft\VisualStudio\14.0Roslyn\ActivityLog.xml

If you could email that to me at I will take a look and see what I can infer. Also a screenshot of the crash dialog's would be helpful.

Thanks for helping us out with this.


Edited, I gave the wrong version number for CTP4.
Oct 29, 2014 at 8:55 PM

Do you run VS14 in administrator mode? When I don't I get into trouble, the kind that are sometimes described as crashes. Did you run into tons of error messages windows every step of the way before it crashed?
Oct 29, 2014 at 9:32 PM

Hello, mate, If it requires administrator privileges then it's broken. In order to diagnose the failures could you provide:

this file:
there is a log file created when VS initializes at: %USERPROFILE%\AppData\Roaming\Microsoft\VisualStudio\14.0Roslyn\ActivityLog.xml

Thank you

Oct 30, 2014 at 6:48 AM
Edited Oct 30, 2014 at 6:49 AM
I would appreciate feedback on the instructions, I am a terrible writer, so all suggestions for improvements will be gratefully received.


Oct 30, 2014 at 6:56 PM
KevinRansom wrote:
Hi Olmo,
To help diagnose the crashes:
there is a log file created when VS initializes at: %USERPROFILE%\AppData\Roaming\Microsoft\VisualStudio\14.0Roslyn\ActivityLog.xml

If you could email that to me at I will take a look and see what I can infer. Also a screenshot of the crash dialog's would be helpful.

Thanks for helping us out with this.

Hi KevinRansom,

Finally VS 14 is working again. I tried repairing VS 14 a few times and didn't work, but uninstalling it completely and installing again did the trick. I will send you the ActivityLog.xml if the problem occours again.

I don't need Administrator privileges to make it work.

I don't expect this to be a "How to make your own compiler" guide, but there are two doubts that are stopping me from making progress:

Doubt 1: If I try to run the tests in CSharpCompilerSemanticTest (Src\Compilers\CSharp\Test\Semantic\Semantics) using xUnit Visual studio runner I get the following error.
------ Discover test started ------
[ 00:00:00.4321351] Skipping: Roslyn.Compilers.CSharp.Semantic.UnitTests.dll (could not find dependent assembly 'Microsoft.CodeAnalysis, Version=0.7.0')
========== Discover test finished: 0 found (0:00:00,6049665) ==========
The procedure in Debugging unit test failures also doesn't work for me but maybe I'm doing something wrong? Is there a way to sue xunit runner instead of this manual procedure?

Doubt 2: By starting OpenSourceDebug I'm able to run Visual Studio Hive, that calls roslyn for tooling, but I want to do a change that has to do with CodeGen ( `add support for null-propagation in expression trees). What should I run then?
Oct 30, 2014 at 10:23 PM
Edited Oct 30, 2014 at 10:24 PM
Doubt 2:
Run it from Roslyn Hive: the Roslyn Hive should be running versions of the compiler and tools built from the local open source codebase.

Doubt 1:
The current work item is to make the open source codebase build, then be debug-able using VS. The current "expected" way of testing the code is using the buildandtest.proj in the root directory of the repo.
This project currently fails pretty quickly because the location to find xunit has changed, I will push a fix for that. Also once that is fixed the debug build has many assertions that should be ignored, and it also seems as if a few tests currently fail. I would urge you and the community to start filing these failures as issues. You could then either provide fixes as pull requests or wait whilst the issue is resolved here. Either way more forward progress will be made.

As for running xunit within VS when we tried it in the past with a project the size of Roslyn the performance was very poor. However we agree it is an area that we believe should work, please raise an issue for it. If you feel able to fix it yourself we would certainly consider a PR to fix this.

Oct 31, 2014 at 1:20 AM
Edited Oct 31, 2014 at 1:21 AM
KevinRansom wrote:
Doubt 2:
Run it from Roslyn Hive: the Roslyn Hive should be running versions of the compiler and tools built from the local open source codebase.
Maybe my version of the compiler runs, but in another process and I can not debug it. I just ran csc with some arguments and it worked.

Here's my first pull request!
Oct 31, 2014 at 7:51 PM

I retried without VS14 priviledges, and it worked without problems. As the errors screen appeared in VS14 and not the hive, I send you VS14's ActivityLog.xml

I suspect those problems doesn't come back in non-administrative mode after you try with administration privileges.
Nov 11, 2014 at 3:35 AM
Does the latest code still require the OpenSourceDebug global environment variable be set by users? I saw some back and forth in the recent commit history and wanted to verify what the latest requirements are.
Nov 12, 2014 at 5:41 PM
Edited Nov 12, 2014 at 6:23 PM

Later today we will be pushing an updated branch "releases/Dev14Preview" to the roslyn repo that matches the Visual Studio 2015 Preview released today. The code in the roslyn branch is not guaranteed to work with the preview build. As has been explained before, Visual Studio and Roslyn are being co-developed, which has the effect that by the time binaries are available for shipping some of the APIs the codebase refers to have changed, which makes for an unreliable experience. This doesn't just affect the OpenSource codebase it also hampers our internal development processes too, with the team standardizing on approved VS builds, that are known to work and then periodically, every couple of weeks or so, standardizing on a new build.

In this release we revised the version number of Roslyn from to We needed to temporarily add binding redirects which unfortunately hinder the open source debugging process we implemented a few weeks ago. We are working on a fix, we will push one as soon as we have a fix for this issue. The tricky part is we need to do it in such a way that we don't break the regular VisualStudio experience of developers when they are not working on the Roslyn OpenSource project.

When I have a solution I will update you.

Nov 12, 2014 at 6:25 PM
@sharwell, the OpenSourceDebug back and forth was because I didn't fully understand the differences between our internal build process and the open source build process for Roslyn. I can confirm that the next iteration of the instructions will not require developers to set that variable.


Nov 12, 2014 at 6:53 PM
Just as an aside -- I would love to move this discussion to a new thread specifically named something like "Using modified Roslyn bits in Visual Studio previews" so that other people can find it if they are looking for it via search. However, I first wanted to see if anyone currently on this thread would object to such a move. (I wanted to reference this thread in another thread, and suddenly realized that anyone wanting to engage on such work would probably not think to look in a thread entitled "Roslyn is Broken :-)") The first entry in that new thread would refer back to this thread to provide any needed back story.

Any objections?

Nov 12, 2014 at 8:34 PM

That would be indeed a good move.


Thanks Kevin.
Nov 12, 2014 at 9:01 PM
Done -- new discussion is at Thanks all, let's move over there!