Visual Studio: How to destroy projects...



  • So, I still have my project. Created it on my desktop, got it working, then had to spend some days at my grandma's. So I put the code into source control, downloaded it onto my laptop and got it working there. Spent some time doing code stuff.

    Then went home again, upon which I loaded the latest version from source control down unto my desktop again.

    Upon which I am now unable to build any of the 4 projects inside my solution. I mean, yes, I need to build them in the proper order of course, but for fuck's sake!
    VS first complains about some missing nuGet packages which are installed (reinstalled, updated, removed, installed again and so forth...) Then it shows me this yellow square in the references which mean "missing files for this reference" or something. But there's no way to fix this.

    Deleting the whole folder and redownloading from source control changed nothing either - only made it more broken by renaming folders for some fucking reason whereupon I promptly got the complaint: "Oh, but you are missing this folder!"

    I FUCKING KNOW: YOU RENAMED IT!

    But I fixed it. I did. By reverting to source control 1.0:

    Creating a zip file of the working project on my laptop, copying it over to my desktop and voilà!

    It works. Yes, I know there's a link to source control in there. I don't fucking care anymore.


  • ♿ (Parody)

    @Rhywden said:

    source control

    What are you using? Also, VS plugin or some external client?



  • @Rhywden said:

    Deleting the whole folder and redownloading from source control changed nothing either - only made it more broken by renaming folders for some fucking reason whereupon I promptly got the complaint: "Oh, but you are missing this folder!"

    This just means that the folders really were out of sync. The yellow icons were proof enough. Something was likely a GAC reference to something you had installed on one machine, and you may have manipulated folders and such locally in a strange way. But mostly, I blame the nuGet packages. They're great when the person who built them isn't a complete idiot, but when they are...

    @Rhywden said:

    But there's no way to fix this.

    Not even slightly true.



  • TFS, not Git (ironically enough).

    @Magus said:

    This just means that the folders really were out of sync. The yellow icons were proof enough. Something was likely a GAC reference to something you had installed on one machine, and you may have manipulated folders and such locally in a strange way. But mostly, I blame the nuGet packages. They're great when the person who built them isn't a complete idiot, but when they are...

    I'm not sure how those folders in question were "out of sync". Because three of the folders were uploaded to source control and not changed since. Only the fourth folder/project was changed in any way - and that fourth one depends on the other three to build, so, not the culprit.


  • :belt_onion:

    @Rhywden said:

    TFS, not Git (ironically enough).

    This means you need to do a @blakeyrant about how sucky TFS is and how Microsoft sucks and everyone should use Git instead.

    Filed Under: I had to



  • Well since you haven't given any indication of what the problem might be, we can't really help you, but I assure you, this is probably the result of a mistake you made, which was perhaps not sufficiently obvious.



  • IB4 "Did I fucking ask for help?"


  • ♿ (Parody)

    @Magus said:

    this is probably the result of a mistake you made,

    Exactly! He insta....nah, too easy.



  • Riiiiiight.

    Solely using "Check In" and "Get Latest Version" obviously is a mistake and I should always consider possible data corruption because I'm not currently using the more advanced commands.



  • I actually figured it out. No thanks to the actual error messages, though.

    When I had first installed the three projects my own project depends upon, the build process complained about "The project xyz depends on the nuGet package Microsoft.Build.Bcl" but it built anyway.

    So, in order to get rid of this message I installed the package. Didn't get rid of the message, though. Project built fine, anyway.

    Then I switched over to my laptop which built the whole thing fine as well.

    Then came the switch back to my laptop. This time the build failed (still giving the same message about MS.Build.Bcl, but nothing else).

    So I used the nuGet package manager to uninstall the package. And now it works.

    Make of that what you will.



  • See, 100% the fault of TFS breaking all your things.



  • You do realize that I installed the same packages on both computers?



  • Did you miss the part where nuGet and TFS aren't the same thing at all, and that I told you straight away that nuGet was probably the problem?



  • Well, there's still the small issue of not replicating the proper folder structure. Which I also fixed.


  • Notification Spam Recipient

    Had this problem myself. The issues with the NuGet packages is that TFS doesn't check in everything in a NuGet package (things like .dll and .js files, for example), so when you download the tree to a new computer things are (obviously) missing, and as you saw it can be very difficult to fix by hand or automatically.

    I essentially had to force-add the entire ./packages folder every time I add a new NuGet package before checking in the tree.



  • @Tsaukpaetra said:

    I essentially had to force-add the entire ./packages folder every time I add a new NuGet package before checking in the tree.

    This isn't really such a good idea. NuGet packages are typically not checked in at all, and are redownloaded the first time you try to build. The problem is, you can't trust some of the people who make the packages to do it right.


  • Notification Spam Recipient

    Yes, it's a hack of a hacked hack. But it works.
    The backstory is that the TFS build machine doesn't have an internet-enabled account in the domain, so when it checks out the source from TFS to build, it can't download the NuGet packages and whines for several lines. Ergo, local copy of the NuGet packages put into TFS. ;)



  • And then you have wonderful situations like Monogame, who released a new version on the release date of VS2015 RTM. That version targets the RC, and the projects it creates are incompatible. I had to edit one manually just to get a working project file. And then the NuGet package they give you has some kind of dependency problem, where it wants some dumb xml file that's in a different path than they think its in, and a bunch of DLLs don't reference eachother right. It was a mess porting my app to 10, and squarely their fault.

    In complaining, I learned that they use Discourse, which was rather enlightening.



  • @Tsaukpaetra said:

    I essentially had to force-add the entire ./packages folder every time I add a new NuGet package before checking in the tree.
    Guidance from the NuGet team says to force-remove ./packages so that NuGet Package Restore will function properly. It's part of their default .gitignore, and should be in .tfignore except the Visual Studio team didn't get the memo.@Tsaukpaetra said:
    TFS build machine doesn't have an internet-enabled account in the domain
    @Tsaukpaetra said:
    internet-enabled account
    :wtf:@Magus said:
    And then you have wonderful situations like Monogame
    Stuff like that makes me wish Microsoft would bring back XNA Game Studio and its Creators Club. That stuff was awesome for like everyone but me, and even I loved its side-effects (Managed DirectX).



  • @Rhywden said:

    But there's no way to fix this.

    (Psst: Visual Studio's project and solution files are just XML. And really well-structured XML. Stuff like this is pretty trivial to fix.)


  • Notification Spam Recipient

    Yeah, for some reason the PM's keep hosing the .tfignore file ("Why are you ignoring files?! It's part of the project, isn't it?!").

    In our domain, users are assigned a specific proxy (there are three per physical location) to use, and if your account isn't in the right Active Directory OU, you ain't getting out of the network (In theory. The previous declaration isn't true, but don't tell the Domain Admins this).
    Of course, the TFS build machine is not joined to the domain at all, nor logging in interactively as a domain user that gets said proxy settings. At least it has credentials to a public share for which to dump the build results, but still, no internet.

    And of course we don't host a local repo in house, why do that when you check the packages into TFS?



  • Well, the thing was that the references flagged as "missing" didn't even appear anywhere when I selected "Add references" for that particular project. In fact, all the tabs were empty. (One tab told me: "All the references that were possible to add already have been added!")

    Not to mention the fun when I re-renamed the directory to what it should be called according to the repository. VS then stated: "Oh, hai, this solution is connected to a repo but I can't connect to it. Please use the 'Change Repo' dialog to fix this!"

    With said dialog consisting of 98% textboxes, buttons and lists in disabled mode, so the only remaining working option was: "Disconnect this solution from any and all repos forever. And no, you can't reconnect. We're never ever getting back together."



  • @Rhywden said:

    Well, the thing was that the references flagged as "missing" didn't even appear anywhere when I selected "Add references" for that particular project. In fact, all the tabs were empty. (One tab told me: "All the references that were possible to add already have been added!")

    Ah, Windows Store? They seem to have relented a bit with Windows 10 Universal, and let you actually add some things.

    I had to manually copy all the SharpDX executables into my solution and reference them from there to run my project at all. People really need to try using their packages some time.


  • Discourse touched me in a no-no place

    @Rhywden said:

    Deleting the whole folder and redownloading from source control changed nothing either - only made it more broken by renaming folders for some fucking reason whereupon I promptly got the complaint: "Oh, but you are missing this folder!"

    I FUCKING KNOW: YOU RENAMED IT!

    That sounds like something found on Text from Xcode...


Log in to reply