Home → Problems →

Resharper Cli Tools failing in builds

• Edit

Rasmus Lauridsen

12 Feb, 2015 09:50 AM

Hi

This morning our builds are suddenly failing because the Jetbrains inspectcode.exe fails.

JetBrains Inspect Code 9.0 Update 1 
Running in 64-bit mode, .NET runtime 4.0.30319.0 under Microsoft Windows NT 6.2.9200.0
Error: 2/12/2015 9:12:55 AM: 
At C:\projects\api-service-events\default.ps1:45 char:9 +     Exec { & $inspect_code_exe $solutionPath /o="$build_dir\resharper.xml" /no-swea ... +            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~ [<<==>>] Exception: Unsupported FrameworkVersion 4.6
Command exited with code

Did you maybe install a new .Net version overnight?

1. Support Staff 1 Posted by Feodor Fitsner on 12 Feb, 2015 11:08 AM

   

   Hi Rasmus,

   Yeah, we've deployed VS 2015 to a Pro image. Is that an issue?

   • Edit

2. 2 Posted by Rasmus Lauridse... on 12 Feb, 2015 11:49 AM

   

   Seems like it is.

   Can't get inspectcode.exe to work.
   As you can see in the example above it craps out saying it doesn't support FrameworkVersion 4.6

   For now I am disabling the code inspections on our builds, though not the ideal solution.

   • Edit

3. 3 Posted by Mattias Karlsso... on 12 Feb, 2015 01:02 PM

   

   Ah, this might be an lead... all out CI builds are failing now... Which well is bad. Will try specifying 4.5 and see if our custom steps start working again...

   • Edit

4. 4 Posted by Rasmus Lauridse... on 12 Feb, 2015 01:07 PM

   

   Looks like 4.6 is an inplace upgrade of .net 4.0 like 4.5.*.

   From: http://www.microsoft.com/en-us/download/details.aspx?id=44928

   The Microsoft .NET Framework 4.6 Preview is a highly compatible, in-place update to the Microsoft .NET Framework 4, .NET Framework 4.5, .NET Framework 4.5.1 and .NET Framework 4.5.2. The web installer is a small package that automatically determines and downloads only the components applicable for a particular platform.

   Not the greatest thing to have a preview framework on a stable build server.

   • Edit

5. 5 Posted by Mattias Karlsso... on 12 Feb, 2015 01:17 PM

   

   Trying to debug our builds... just as a long shot I added <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" /> still get weird null exceptions i didn't get before.

   Hard for me to debug... as everything works locally both for developers and local ci servers.

   Might be something in our code, just not the parts I wanted to debug today...

   • Edit

6. 6 Posted by Rasmus Lauridse... on 12 Feb, 2015 01:25 PM

   

   I've tried running inspectcode on an Azure VS2015 vm adding an inspectcode.exe.config file with supportedRuntime and sku.

   Still the same reaction from inspectcode :-(

   <?xml version="1.0" encoding="utf-8"?>
   <configuration>
     <startup>
       <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
     </startup>
   </configuration>
   

   • Edit

7. Support Staff 7 Posted by Feodor Fitsner on 12 Feb, 2015 01:33 PM

   

   We are going to roll back the image to the previous state, without VS 2015.

   -Feodor

   • Edit

8. 8 Posted by Mattias Karlsso... on 12 Feb, 2015 01:36 PM

   

   Cool, I have a little more than 20 projects failing, so I have test cases when rolled back :)

   /Mattias

   • Edit

9. 9 Posted by Rasmus Lauridse... on 12 Feb, 2015 01:44 PM

   

   Very cool Feodor :-)

   Thank you

   Just heard back from Jetbrains support and they have an EAP2 version that should work with v4.6
   https://confluence.jetbrains.com/display/ReSharper/ReSharper+9.1+EAP

   This of course doesn't fix Mattias problem, but someone might come by and read this later after 4.6 is released. :-)

   Rasmus

   • Edit

10. 10 Posted by Mattias Karlsso... on 12 Feb, 2015 01:49 PM

    

    What we need is like Asp.net vNext we need static linking for .Net console apps.

    Things like these are stigmatizing, leaves scars and old pain.

    If we have an 4.6 issue we will have to look at it and deal with it, but preferable not in production though;)

    /Mattias

    • Edit

11. Support Staff 11 Posted by Feodor Fitsner on 12 Feb, 2015 01:51 PM

    

    Sure! Sorry for that.

    • Edit

12. 12 Posted by Mattias Karlsso... on 12 Feb, 2015 04:28 PM

    

    Any planned ETA when it will be in production?

    Regards,
    /Mattias

    • Edit

13. Support Staff 13 Posted by Feodor Fitsner on 12 Feb, 2015 04:32 PM

    

    Less than an hour.

    -Feodor

    • Edit

14. Support Staff 14 Posted by Feodor Fitsner on 12 Feb, 2015 05:32 PM

    

    OK, should be fine now. Thanks for your patience.

    • Edit

15. 15 Posted by Mattias Karlsso... on 12 Feb, 2015 06:49 PM

    

    Hi,

    Can confirm all builds completed successfully now.

    Regards,
    /Mattias

    • Edit

16. Support Staff 16 Posted by Feodor Fitsner on 12 Feb, 2015 06:52 PM

    

    Great! Once again, sorry for the inconveniences!

    • Edit

17. 17 Posted by Mattias Karlsso... on 12 Feb, 2015 07:36 PM

    

    Hi,

    Good that it works, this wasn't an great experience for us.

    Hope you realized that and learned from it, AppVeyor is starting to become a critical part of our dev cycle. Or trust in the service got a little scar today.

    Publishing beta bits into a what I perceive as a stable environment isn't acceptable.

    Though, there will be a time when upgrading is essential and you must to it, security updates, support cycle, etc. So perhaps you could have 1 previous vm version available to be selectable? So we can have i.e.
    Previous Windows 2012 R2
    Current Windows 2012 R2
    Unstable Windows 2012 R2

    This would allow us to quickly switch to previous version if similar issues would occur again, have all our builds and deployments work, while solving any issues in our code in a less pressing way.

    Regards,
    /Mattias
    ________________________________

    • Edit

18. Support Staff 18 Posted by Feodor Fitsner on 13 Feb, 2015 05:59 AM

    

    I understand your concerns. I broke a fragile balance between providing new features and stability!
    But lesson learned and we are going to work on improving the process of deploying environment updates.

    I appreciate your thoughts regarding images versioning - sounds like a good idea.
    We could have multiple images on Azure. Builds there are slower, but it can be a good remedy in case of "disaster" or if you need to test upcoming updates.

    I'd like to keep this discussion open in case I have some questions to you guys.

    • Edit

19. 19 Posted by Mattias Karlsso... on 13 Feb, 2015 06:15 AM

    

    Hi,

    Excellent , understand there's complexity around this! Many moving parts.
    Previous version doesn't have to be fast, just so we/you can have some breathing room in case of any issue, so fine with an slower Azure instance that works so our production still build & deploys.

    Happy to discuss any ideas or questions you might have.

    Regards,
    /Mattias

    Sent from my Windows Phone
    ________________________________

    • Edit

20. 20 Posted by Rasmus Lauridse... on 13 Feb, 2015 07:30 AM

    

    I agree completely

    I understand the pressure to have the newest stuff up there since there are people clamoring for the newest bits. It is a delicate balance, but I think Mattias' suggestion has a lot of merit, with the stable, previous and testing images.

    Being able to go back to a slower, but working, environment is definitely better than being stuck in a non working one.

    Regards
    Rasmus

    • Edit

21. Support Staff 21 Posted by Feodor Fitsner on 27 Feb, 2015 05:36 AM

    

    Hi guys,

    Just to let you know that with the latest AppVeyor update we started providing previous build worker images:
    http://www.appveyor.com/updates/2015/02/26

    • Edit

22. 22 Posted by Mattias Karlsso... on 27 Feb, 2015 06:50 AM

    

    Superb! That's an excellent feature !

    Sent from my Windows Phone
    ________________________________

    • Edit

23. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 01:54 AM.