Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StackOverflowException in o-shell #192

Open
haf opened this issue May 16, 2011 · 3 comments
Open

StackOverflowException in o-shell #192

haf opened this issue May 16, 2011 · 3 comments

Comments

@haf
Copy link
Contributor

haf commented May 16, 2011

First o add-wrap Newtonsoft.Json on a 'clean machine'.

Watch the build fail, because the dll name is 'Newtonsoft.Json.net35.dll'.

Download the nuget package.

Rename the dlls in the nuget package explorer. Save the nuget package locally.

As you haven't yet removed the wrap you still have the old stuff in owrap.

o remove-wrap Newtonsoft.Json in project directory. I also o publish-wrap -Remote locally -Path .../Newtonsoft.Json.wrap.

I tried to re-add it. Same old Newtonsoft. Remove wrap, try to nuke it. Nuke returns some errors.

I went to %LOCALAPPDATA%\wraps and removed it and its directory in _cache. Removed it from project's cache. Ran

o add-wrap newtonsoft.json. wait... stack overflow.

@serialseb
Copy link
Member

I'll assume the package was still in the system repository (as it's teh default on add-wrap in 1.0). As packages are supposed to be immutable, and as you probably didn't change the version of the package, OW just copied from a closer location to your remote, aka the sys repository.

Nuking on the remote works if it has been published correctly (aka with the correct metadata). Nuking will only remove one specific version of a pacakge from a remote. As I assume you have the nuget repository added, and assuming you havent' changed the version number, then OW will either ignore the remotes completely (as it's already in system), or use the nuget repo (as the package is available there).

To debug the error, knowing what kind of error the nuke triggered would be beneficial.

Finally, the stack overflow I'm not sure I know how to diagnose that. Is this using OW 1.0 or 1.1? If it's the former, I don't know, and would need a repro with more details (the package binary, the content of the project descriptor and associated files, the list of what ends up in the system).

If however it's OW 1.1, there has been a specific issue under which OW would generate a stackoverflow (in the case of self-referencing packages in the pacakge visitor) which ahs been fixed in later versions.

@haf
Copy link
Contributor Author

haf commented May 16, 2011

I can give you remote access to my machine for you to debug it.

It would be really nice to get that 1.1 -- I would love some improvements in speed when adding and listing and more output to see what is going on, possibly with flags to alter the behavior to make it faster.

A method of publishing packages without network shares would also be really great. Perhaps even through github, which is what we're using now as we're not in a domain.

And packages that don't measure up, like newtonsoft: an editor like the nupkg one so that it can be fixed manually. Or a way of specifying that owrap should only look in the net40 folder.

I can probably give you a hand next week or during this weekend, if you want -- but how much do you think is left till 1.1 official?

-----Original Message-----
From: serialseb [mailto:reply@reply.github.com]
Sent: den 17 maj 2011 00:25
To: henrik@haf.se
Subject: Re: [openwrap] StackOverflowException in o-shell (#192)

I'll assume the package was still in the system repository (as it's teh default on add-wrap in 1.0). As packages are supposed to be immutable, and as you probably didn't change the version of the package, OW just copied from a closer location to your remote, aka the sys repository.

Nuking on the remote works if it has been published correctly (aka with the correct metadata). Nuking will only remove one specific version of a pacakge from a remote. As I assume you have the nuget repository added, and assuming you havent' changed the version number, then OW will either ignore the remotes completely (as it's already in system), or use the nuget repo (as the package is available there).

To debug the error, knowing what kind of error the nuke triggered would be beneficial.

Finally, the stack overflow I'm not sure I know how to diagnose that. Is this using OW 1.0 or 1.1? If it's the former, I don't know, and would need a repro with more details (the package binary, the content of the project descriptor and associated files, the list of what ends up in the system).

If however it's OW 1.1, there has been a specific issue under which OW would generate a stackoverflow (in the case of self-referencing packages in the pacakge visitor) which ahs been fixed in later versions.

Reply to this email directly or view it on GitHub:
#192 (comment)

@serialseb
Copy link
Member

Packages for 1.1 are available from http://wraps.openwrap.org/beta/ but it's not beta-quality yet. You can check the 1.1 open issues / features in the bug tracker.

Publishing through github would be an interesting idea that has been suggested a couple of times. The repository support has been overhauled for 1.1 and one of the 1.2 features will be pluggable repository types, so that's certainly something that could be added later.

The problem of assembly imports when they're named weird stems from how nuget packages are layed out. There's a bug entry to ensure that explicit assembly reference declarations can be done per framework profile/platform, it'll then be a matter of adding those entries to the nuget converter.

Ping me on skype if you wanna help on various bits. 1.1 is only missing a few main features and a lot of polish on the commands. A beta will be put forward as soon as we have the main two (cached repos and namespace support) implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants