Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to dotnet tooling 1.0 #35

Merged
merged 4 commits into from
Mar 9, 2017
Merged

Migrate to dotnet tooling 1.0 #35

merged 4 commits into from
Mar 9, 2017

Conversation

mrahhal
Copy link
Owner

@mrahhal mrahhal commented Mar 9, 2017

Original PR at #34

@Abdruggi I had to get this out asap since some of the internal projects I work on are already migrated. I used your commit as a reference since you've done a lot of the work (the first commit is still attributed to you so thanks a lot).

That being said, there are still things to be done. This branch as it is right now works, but we're calling an external process manually when running some operations, and this is showing a temp console window (yikes). I'd like to improve on some of the other points too (like the ProjectReader).

@mrahhal mrahhal self-assigned this Mar 9, 2017
This was referenced Mar 9, 2017
@Abdruggi
Copy link
Contributor

Abdruggi commented Mar 9, 2017

I wrote the change set out of the same reason. Just write me if I can help refactoring/improve the project. I was hoping Microsoft will bring an official package. But it doesn’t look like.

@AlonCG
Copy link

AlonCG commented Mar 9, 2017

Thanks all!

@mrahhal
Copy link
Owner Author

mrahhal commented Mar 9, 2017

@Abdruggi I definitely will. You can review the first commit which I really took from your work, kept it the same just cleaned a bit.

The only major thing I want to change before I release 1.1.0 is this. I'm already looking into whether dispatching will do what we want.

I was hoping Microsoft will bring an official package.

Actually, the only reason I didn't attempt to do the migration the moment VS RC got out is because I genuinely thought there would be something that works at RTM (because it's the first stable tooling version and all). But appears nothing is planned at all.

@mrahhal
Copy link
Owner Author

mrahhal commented Mar 9, 2017

OK so that was easy, right now everything works as expected. But I'm still not a lot happy with ProjectReader, seems like a roundabout way to get common info about the target project. There must be something that we can use (or maybe there isn't? Which sounds extremely odd).

@Abdruggi
Copy link
Contributor

Abdruggi commented Mar 9, 2017

Parsing of csproj files is not that easy because of conditions. The environment you compile against determines the final values. I will do some research this evening.

@mrahhal
Copy link
Owner Author

mrahhal commented Mar 9, 2017

I was hoping the sdk itself will give us a public api for that. I mean, obviously the dotnet command parses the project so I was wondering why that functionality isn't exposed.

But this is good enough for now. I'll make a final review before releasing.

@mrahhal mrahhal merged commit cc7ca8f into master Mar 9, 2017
@mrahhal mrahhal deleted the dotnet1 branch March 9, 2017 14:15
@Abdruggi
Copy link
Contributor

Abdruggi commented Mar 9, 2017

Yes that would be desirable. Or maybe some Roslyn API‘s to get the information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants