Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Sam Harwell
    @sharwell
    Here's my recommendation:
    1. File bug reports when you can
    2. Add comments to issues reported by other people that are affecting you, to help us triage the most important items in the time we have available
    3. (Bonus points) Help us figure out why it's not working and fix it :smile:
    jbcutting
    @jbcutting
    I at least know the issues and can disable the editor extension and tell my team to look at the output window for the other issue. But everyone getting these from the VS gallery has no knowledge of those and nobody's telling them the issues.
    Sam Harwell
    @sharwell
    Messaging is something we can (hopefully) work on after the project is turned over to the community. I'm not sure what the time frame is for that or exactly how it will work.
    jbcutting
    @jbcutting
    It's not even really about me at this point... I know the issues and can work around them. I'm concerned for all the people who are going to go download these with no knowledge and lose time figuring them out..
    As a former developer at Microsoft myself, I can say that this is the kind of stuff MS usually at least communicates so people are aware...
    Sam Harwell
    @sharwell
    Can you get me a list of the issues you would consider "essential" for a successful release? It might be short enough that we can get it done in a reasonably short period of time.
    jbcutting
    @jbcutting
    For CC itself, there's just the one that I know of since it hides important output from users. For the editor extension, I'd say it's just stopping the regular crash. But paramount over fixing either, I think the big known issues should be listed on the VS gallery posts.
    Sam Harwell
    @sharwell
    @jbcutting Found them. They're in the Task List (View → Task List)
    jbcutting
    @jbcutting
    Weeeeird. I wonder why they're there now.
    I doubt anyone who's used to them being in messages/warnings would look there... I definitely wouldn't havea.
    I wonder if that's a VS2015 bug.
    Sam Harwell
    @sharwell
    Could be a bug, but I know how to work around it too
    Sam Harwell
    @sharwell
    @jbcutting Probably not a bug in VS 2015
    I think I figured out why it's broken
    Sam Harwell
    @sharwell
    @SergeyTeplyakov I need #162 merged before I can send a pull request for fixing #137
    Sam Harwell
    @sharwell
    @jbcutting It actually was a case where a bug was fixed in Visual Studio 2015. These messages never should have gone to the errors window in any version of Visual Studio.
    Sam Harwell
    @sharwell
    @jbcutting your build should be ready in 15 minutes
    I have not tested it, but I should know by that time whether or not the build will work :D
    Sergey Teplyakov
    @SergeyTeplyakov
    merged #162
    Sam Harwell
    @sharwell
    Thanks :)
    @SergeyTeplyakov I'm having trouble with the code tools
    I made a change to TaskManager.dll but the build isn't picking it up.
    (I did not make any changes to ITaskManager.dll)
    Sam Harwell
    @sharwell
    I figured it out. The binaries are embedded in ImportedCodeTools\CodeTools.msm. I need to update buildCC to rebuild that file during a build.
    Sergey Teplyakov
    @SergeyTeplyakov
    Sorry, didn't noticed you message, but glad that you figured that out! I had no idea about that stuff:)
    Sam Harwell
    @sharwell
    blob
    @jbcutting So this :arrow_up:
    @SergeyTeplyakov I'm waiting for an AppVeyor build of that branch to complete before sending a pull request. I want to make sure it's not depending on some sort of local system state specific to my machine.
    I'll check back in about an hour
    The AppVeyor build will actually create an installer and attach it to the build result, so @jbcutting can test it as soon as he wants
    (Assuming the build is successful of course)
    It's this build (ignore the summary message - I intentionally cherry-picked the fix for 161 into this branch knowing someone is likely to actually install it)
    build failed, will fix after some tv time
    Sam Harwell
    @sharwell
    Later than I thought; resuming tomorrow.
    Sam Harwell
    @sharwell
    New build which I'm hoping works (it's queued; link will work as soon as it starts): https://ci.appveyor.com/project/sharwell/codecontracts/build/1.9.10722.26
    Sam Harwell
    @sharwell
    jbcutting
    @jbcutting
    I tried out that build, but I'm still not seeing the messages and warnings in the 'error list' window... :(
    Sam Harwell
    @sharwell
    @jbcutting it still failed
    I can't figure out the path to tlbexp on the AppVeyor machine
    I tried tlbexp first, then $(WindowsSDKDir)\tlbexp.exe
    Now I'm trying $(TargetFrameworkSDKToolsDirectory)\tlbexp.exe
    Sam Harwell
    @sharwell
    Now I'm trying $(WindowsSDKDir)Bin\tlbexp.exe
    Sam Harwell
    @sharwell
    Now I'm trying just tlbexp again, but I updated appveyor.yml to call SetEnv.bat according to this message.
    Sam Harwell
    @sharwell
    I gave up and put TlbExp.exe in the repo
    Let me know if those work
    Sam Harwell
    @sharwell
    Installing that AppVeyor artifact MSI worked for me :tada:
    Sam Harwell
    @sharwell
    Would anyone have a major objection to changes to CodeContracts.sln which require Visual Studio 2015, if it means it's easier to use overall?
    In particular, I'm thinking of splitting each of the reference contract projects into a shared project containing the source code, and separate projects for each target (.net 3.5, silverlight, 4.5, etc.). I'd also like to migrate towards using analyzers to verify you have the correct APIs defined in the reference contract assemblies while you work.
    Shared projects may work in 2013, but they certainly work well in 2015. Analyzers are only 2015+.