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
    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+.
    jbcutting
    @jbcutting
    @sharwell Thanks - I'll try out that newer build here shortly.
    Sam Harwell
    @sharwell
    When you do, can you uninstall the old one before installing the new one?
    jbcutting
    @jbcutting
    yes
    Sam Harwell
    @sharwell
    It works either way, but I want to see if #161 shows up for you if you uninstall and reinstall. I installed it right over the top of the previous one and #161 did appear for me, even though it should be fixed.
    jbcutting
    @jbcutting
    I usually do (when I actually install it... I usually just extract the binaries with msiexec and move them into my Tools folder where we have them in our source tree)
    ok
    I can install it to verify that.
    Sam Harwell
    @sharwell
    Fixing your primary issue required updating the CodeTools binaries, which you probably don't include in your source tree.
    jbcutting
    @jbcutting
    I'll check, but why would that be the case? The analysis was outputting messages in the MSBuild format. VS adds messages in that format to the errors list.
    Sam Harwell
    @sharwell
    Oh trust me, it does not work like that :(