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
    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
    Failed again, last try for the night: https://ci.appveyor.com/project/sharwell/codecontracts/build/1.9.10722.27
    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
    Sam Harwell
    @sharwell
    @jbcutting Here you go https://ci.appveyor.com/project/sharwell/codecontracts/build/1.9.10722.32/artifacts
    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.
    That's how it was working in VS2013. Here's some relevant info: http://blogs.msdn.com/b/msbuild/archive/2006/11/03/msbuild-visual-studio-aware-error-messages-and-message-formats.aspx
    Sam Harwell
    @sharwell
    Oh trust me, it does not work like that :(
    @jbcutting so did this build fix it?? :)
    jbcutting
    @jbcutting
    Sorry, got pulled into a discussion with our PM... I'll try to get it tested now.
    I'm still confused, though, because it has been working like that for us in VS2013. We don't require all devs to have the code contracts MSI installed since it's in our source tree and they get the warnings/messages without it.
    Sam Harwell
    @sharwell
    Maybe it will work then.
    If it works like that it would be awesome. Puts us a big step ahead in the goal to only distribute via NuGet+VS Gallery eventually (no msi installer)
    jbcutting
    @jbcutting
    Still verifying, but I think it's working as it should now. I actually uninstalled CC completely and only updated the binaries in the source tree and I'm getting a warning in my errors list. So that's promising, but give me another ten mins or so to check a few more things.
    Sam Harwell
    @sharwell
    Exciting!
    Note that I haven't fixed the bugs that result in crash reports