Visual Studio, Xamarin and Nuget...
-
So, I was happily trying out new stuff, testing the water, so to speak with a Xamarin project in VS2017 when it happened: Visual Studio suddenly reported that it couldn't find a nuget-package.
What had changed? Nothing. Because all I had done was take a pause, shutdown the PC and the power it up again. Reinstalling the package did not help - VS told me that it's installed, the files are physically on the disc but any build fails. For the Android part, mind. The PCL and UWP part of the project work just fine. Then I tried almost everything else and now it looks like this:
It also does this on a different computer, by the way.
If I'm using the nuget CLI I'm only getting a bunch of moronic error messages. This is working great...
... anybody have an idea where this comes from? Because this is actually the second time I encountered this.
-
@Rhywden said in Visual Studio, Xamarin and Nuget...:
If I'm using the nuget CLI I'm only getting a bunch of moronic error messages.
What sort of error messages?
-
@RaceProUK I didn't jot them down before burning down the house. But as it just showed, the problem seems to be somewhere else.
Because I just created a new blank Xamarin Project. Visual Studio immediately told me that there was "some kind of error" (that actually is verbatim) and that I should restart VS. Before I did so, however, I was able to start both the UWP and the Android project succesfully.
Then I restarted VS, loaded the solution and got the helpful error box (yes, an actual Alert Box!) "At least one error occured" and now the references for the Android project look like this:
See that yellow exclamation there?
-
Let's see if a "Repair" of my VS installation does any good.
-
@Rhywden said in Visual Studio, Xamarin and Nuget...:
Let's see if a "Repair" of my VS installation does any good.
I've had this in the last week. Generally just restart VS clears it.
-
@Karla said in Visual Studio, Xamarin and Nuget...:
@Rhywden said in Visual Studio, Xamarin and Nuget...:
Let's see if a "Repair" of my VS installation does any good.
I've had this in the last week. Generally just restart VS clears it.
In my case, no. I restarted, rebooted, pruned everything project-related from disc and pulled it down from the Git repo again - nothing helped.
-
Okay, so, trying to update the nuget packages seems to be an equally bad idea:
Do they actually test that stuff at all?
-
@Rhywden said in Visual Studio, Xamarin and Nuget...:
Do they actually test that stuff at all?
It compiles ?
SHIP IT !!!
-
-
@Rhywden said in Visual Studio, Xamarin and Nuget...:
Okay, so, trying to update the nuget packages seems to be an equally bad idea:
Do they actually test that stuff at all?
Maybe try nuget at the command line? Might give a more helpful error...
If only there was a way to do things without dropping to a command line
-
Access denied for path "C:\Repos\Fios-Xamarin\packages\Xamarin.Android.Support.Vector.Drawable.23.3.0\build\Xamarin.Android.Support.Tasks.VectorDrawable.dll"
-
Okay, it does this even when I run VS as an administrator. It's also always the same package. And I can't see anything special about this particular package
-
@Rhywden Is the offending DLL marked read-only? I think
attrib -r /S /D C:\Repos\Fios-Xamarin\packages
Should strip read-only from everything recursievly.
-
Going through some solutions today to update some packages, and I ran into a very similar issue to @Rhywden, although my project built without error. So, I went and updated a bunch of packages (none that were failing to resolve), restarted VS2015 when prompted... and everything was fine again
Dunno of this'll help @Rhywden or not, but I'm sharing just in case.
-
What OS is this?
There is a file too long exception. Try moving the solution folder to C:\dev or similar.
Windows before Windows 10 had a maximum file path length of 255 characters.
copy and pasting the path in the python len command gives me the following.
C:\Users\lukea>python Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> len('C:\Repos\Fios-Xamarin\packages\Xamarin.Android.Support.Vector.Drawable.23.3.0\build\Xamarin.Android.Support.Tasks.VectorDrawable.dll') 131 >>>
If you have a \bin<dllname> you will be getting close to that limit.
-
@lucas1 said in Visual Studio, Xamarin and Nuget...:
Windows before Windows 10 Anniversary Update had a maximum file path length of 2
5560 characters.
-
@dcon Thanks for the correction. I probably thought it was 255 characters because that is the largest 8bit number.
But it is totally possible the file paths are too long if he is running and older version of Windows.
-
@lucas1 said in Visual Studio, Xamarin and Nuget...:
Thanks for the correction.
I was only able to do that as it just came up in a different thread. I didn't know about that until then...
https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/
-
@sloosecannon It literally says "path is too long exception". That is what is wrong.
Also btw. If you aren't sure what the VS compiler is doing. Make sure you have the output window pinned. It will tell you far more than the summary VS gives you.
I've been working with VS now for over a decade.
-
@dcon I thought they made the change at with Win 10. TBH after NPM 3.X it hasn't been much of a issue for me.
However most projects are on a VHD that is mounted under X:\
-
@lucas1 said in Visual Studio, Xamarin and Nuget...:
TBH after NPM 3.X it hasn't been much of a issue for me.
npm v3 flattened the
node_modules
hierarchy, which is why it's not an issue anymore
-
@RaceProUK I know.
-
@dcon said in Visual Studio, Xamarin and Nuget...:
@lucas1 said in Visual Studio, Xamarin and Nuget...:
Windows before Windows 10 Anniversary Update had a maximum file path length of 2
5560 characters.Linux had a maximum path length of 4096 characters for as long as I can remember.
Good thing Windows is finallyfixing this shitcatching up
-
@TimeBandit Windows or NTFS didn't have a problem with long filepaths. It is a compatibility issue I believe. I think it is a Win32 limit.
Anyway @Rhywden problem is long file path on probably something before Windows 10 Anniversary Update.
-
@lucas1 said in Visual Studio, Xamarin and Nuget...:
It is a compatibility issue I believe. I think it is a Win32 limit.
FAT32 I think, but yeah, it's an old limit either way
-
@RaceProUK said in Visual Studio, Xamarin and Nuget...:
FAT32 I think, but yeah, it's an old limit either way
And we've been using NTFS since at least Win2k, except maybe for USB flash drives and the like.
-
@lucas1 said in Visual Studio, Xamarin and Nuget...:
@sloosecannon It literally says "path is too long exception". That is what is wrong.
Also btw. If you aren't sure what the VS compiler is doing. Make sure you have the output window pinned. It will tell you far more than the summary VS gives you.
I've been working with VS now for over a decade.
-
@sloosecannon Nope.
-
@TimeBandit The interesting thing is, the limit has never applied to anything that uses UNC paths, only drive-rooted ones.
-
@Magus Nice to know.
-
@TimeBandit said in Visual Studio, Xamarin and Nuget...:
@RaceProUK said in Visual Studio, Xamarin and Nuget...:
FAT32 I think, but yeah, it's an old limit either way
And we've been using NTFS since at least Win2k, except maybe for USB flash drives and the like.
well that and programs with static buffers for file paths. i guarantee removing the limit will break some popular program when it encounters those paths.
-
@accalia said in Visual Studio, Xamarin and Nuget...:
i guarantee removing the limit will break
someheaps of popular programs
-
I am suggesting to try "Long Path Tool" program.
-
@magus said in Visual Studio, Xamarin and Nuget...:
@TimeBandit The interesting thing is, the limit has never applied to anything that uses UNC paths, only drive-rooted ones.
False. Had this issue in Excel 2013.
-
@mccarty82 said in Visual Studio, Xamarin and Nuget...:
I am suggesting to try "Long Path Tool" program.
Welcome to the forums!
....
But, joining to necro a thread? Kids these days... ;P
-
@tsaukpaetra Does that make @fbmac a hipster because he necro'd before it was cool?
-
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
@magus said in Visual Studio, Xamarin and Nuget...:
@TimeBandit The interesting thing is, the limit has never applied to anything that uses UNC paths, only drive-rooted ones.
False. Had this issue in Excel 2013.
It depends on the APIs in use.
-
@weng said in Visual Studio, Xamarin and Nuget...:
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
@magus said in Visual Studio, Xamarin and Nuget...:
@TimeBandit The interesting thing is, the limit has never applied to anything that uses UNC paths, only drive-rooted ones.
False. Had this issue in Excel 2013.
It depends on the APIs in use.
Microsoft is ? Say it isn't so!
Of course it depends on what you're doing to get there. Problem is, everyone (probably rightly) agrees that walking the tree is slow AF and almost never does it "the right way".
-
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
@weng said in Visual Studio, Xamarin and Nuget...:
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
@magus said in Visual Studio, Xamarin and Nuget...:
@TimeBandit The interesting thing is, the limit has never applied to anything that uses UNC paths, only drive-rooted ones.
False. Had this issue in Excel 2013.
It depends on the APIs in use.
Microsoft is ? Say it isn't so!
Of course it depends on what you're doing to get there. Problem is, everyone (probably rightly) agrees that walking the tree is slow AF and almost never does it "the right way".
If I'm not mistaken, the APIs in question originated in Win9x and correspond to limitations of the FAT filesystems.
Upgrading them transparently would be Problematic because suddenly they might return values that overflow fixed size data fields. It was assumed that programmers writing modern software would use modern APIs. We all know how well that shit turned out.
I suspect the recent widespread release of unlimited path lengths comes from Microsoft having finally finished writing compatability shims for every shitty 1990s Lotto Simulator game.
-
@weng said in Visual Studio, Xamarin and Nuget...:
I suspect the recent widespread release of unlimited path lengths comes from Microsoft having finally finished writing compatability shims for every shitty 1990s Lotto Simulator game.
And what would that even do? Return a path that magically fit in 260 characters but wasn't a real path anywhere at any time but got magically converted back when opened?
That's an even bigger rabbit hole sir...
-
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
@weng said in Visual Studio, Xamarin and Nuget...:
I suspect the recent widespread release of unlimited path lengths comes from Microsoft having finally finished writing compatability shims for every shitty 1990s Lotto Simulator game.
And what would that even do? Return a path that magically fit in 260 characters but wasn't a real path anywhere at any time but got magically converted back when opened?
That's an even bigger rabbit hole sir...
That is EXACTLY what they do. They do the same thing for apps that have hardcoded paths to Documents and Settings. Or system32 when they are running in a 32bit context on a 64bit system (they mean to be looking in syswow64). Or dozens of other things.
A lesser technique is to repackage the shitty old broken API and redirect calls to the shitty old broken API depending on who's calling. So the bustassed apps retains the limitation but nobody else can use it anymore. This tends to be used more when apps used undocumented APIs that were subject to change anyway.
Fuck, you ever notice that when we transitioned to Win64, all your old early 32bit stuff with 16bit installers still worked? That's because Microsoft literally ported the fucking common installer platforms and included them in the OS and substitutes the executable at runtime.
-
@weng said in Visual Studio, Xamarin and Nuget...:
all your old early 32bit stuff with 16bit installers still worked?
No, they didn't still worked. Either that or
@weng said in Visual Studio, Xamarin and Nuget...:
the fucking common installer platforms and included them in the OS and substitutes the executable at runtime.
They stopped doing that. Because they were obviously running out of room in their I-almost-can't-fit-this-thing-on-a-DVD-anymore OS.
-
@weng said in Visual Studio, Xamarin and Nuget...:
Fuck, you ever notice that when we transitioned to Win64, all your old early 32bit stuff with 16bit installers still worked? That's because Microsoft literally ported the fucking common installer platforms and included them in the OS and substitutes the executable at runtime.
And that's why Windows is so large: half if it is shims to keep all those shitty finance programs from 1993 running exactly as they did 24 years ago.
-
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
@weng said in Visual Studio, Xamarin and Nuget...:
all your old early 32bit stuff with 16bit installers still worked?
No, they didn't still worked. Either that or
@weng said in Visual Studio, Xamarin and Nuget...:
the fucking common installer platforms and included them in the OS and substitutes the executable at runtime.
They stopped doing that. Because they were obviously running out of room in their I-almost-can't-fit-this-thing-on-a-DVD-anymore OS.
Might not still be there anymore, but it was there in XP64/Vista/7. If you hadn't migrated to 64bit by the time 8 came around, you're a luddite who deserves to be punished.
-
@weng said in Visual Studio, Xamarin and Nuget...:
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
@weng said in Visual Studio, Xamarin and Nuget...:
all your old early 32bit stuff with 16bit installers still worked?
No, they didn't still worked. Either that or
@weng said in Visual Studio, Xamarin and Nuget...:
the fucking common installer platforms and included them in the OS and substitutes the executable at runtime.
They stopped doing that. Because they were obviously running out of room in their I-almost-can't-fit-this-thing-on-a-DVD-anymore OS.
Might not still be there anymore, but it was there in XP64/Vista/7. If you hadn't migrated to 64bit by the time 8 came around, you're a luddite who deserves to be punished.
Punish me and my luddite-ness, for I still keep a laptop with Windows 2008 on it because fax server.
Edit: Also:
Edit edit: Though it does work in XP, so there's that:
-
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
@weng said in Visual Studio, Xamarin and Nuget...:
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
@weng said in Visual Studio, Xamarin and Nuget...:
all your old early 32bit stuff with 16bit installers still worked?
No, they didn't still worked. Either that or
@weng said in Visual Studio, Xamarin and Nuget...:
the fucking common installer platforms and included them in the OS and substitutes the executable at runtime.
They stopped doing that. Because they were obviously running out of room in their I-almost-can't-fit-this-thing-on-a-DVD-anymore OS.
Might not still be there anymore, but it was there in XP64/Vista/7. If you hadn't migrated to 64bit by the time 8 came around, you're a luddite who deserves to be punished.
Punish me and my luddite-ness, for I still keep a laptop with Windows 2008 on it because fax server.
Edit: Also:
Edit edit: Though it does work in XP, so there's that:
So what I said is that Microsoft ported the 16-bit INSTALLERS that were commonly used by Win9x era 32bit applications - not that they ported 16-bit applications. WSLAM.EXE doesn't appear to be InstallShield or similar.
-
@weng said in Visual Studio, Xamarin and Nuget...:
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
@weng said in Visual Studio, Xamarin and Nuget...:
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
@weng said in Visual Studio, Xamarin and Nuget...:
all your old early 32bit stuff with 16bit installers still worked?
No, they didn't still worked. Either that or
@weng said in Visual Studio, Xamarin and Nuget...:
the fucking common installer platforms and included them in the OS and substitutes the executable at runtime.
They stopped doing that. Because they were obviously running out of room in their I-almost-can't-fit-this-thing-on-a-DVD-anymore OS.
Might not still be there anymore, but it was there in XP64/Vista/7. If you hadn't migrated to 64bit by the time 8 came around, you're a luddite who deserves to be punished.
Punish me and my luddite-ness, for I still keep a laptop with Windows 2008 on it because fax server.
Edit: Also:
Edit edit: Though it does work in XP, so there's that:
So what I said is that Microsoft ported the 16-bit INSTALLERS that were commonly used by Win9x era 32bit applications - not that they ported 16-bit applications. WSLAM.EXE doesn't appear to be InstallShield or similar.
-
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
@mccarty82 said in Visual Studio, Xamarin and Nuget...:
I am suggesting to try "Long Path Tool" program.
Welcome to the forums!
....
But, joining to necro a thread? Kids these days... ;P
A spambot necroed another thread that was from 2004 in the IHOC category. I only know it was a spambot because their comment was anti-Oracle but the link in their comment went to an Oracle training ad with the same name as their account.
-
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
But, joining to necro a thread? Kids these days... ;P
More like, joining to promote his program.
-
@anonymous234 said in Visual Studio, Xamarin and Nuget...:
@tsaukpaetra said in Visual Studio, Xamarin and Nuget...:
But, joining to necro a thread? Kids these days... ;P
More like, joining to promote his program.
One can dream...