Comments (15)
We solved the issue locally by changing the call in Sharpen.RunTime.cs.Getenv(string var) to Environment.GetEnvironmentVariable(var, EnvironmentVariableTarget.User)
from ngit.
Also worth noting that the IIS 7.5 settings for the website/webservice need to be
Anonymous Auth: Enabled
ASP.Net Impersonation: Enabled (and there has to be a named account)
(everything else Disabled)
Then you'll also need to add env variables under the named account on the server for HOMEDRIVE and HOMEPATH
from ngit.
Is this still an issue with the latest NGit code? We fixed something similar recently so if it does not fix your issue, please let me know and we'll get a fix merged in.
from ngit.
Hi Alan,
Many thanks for your post.
When you mention a similar issue, I think you are referring to "user.home should come from Environment.SpecialFolder.UserProfile". This does not address this issue which occurs in FS_Win32.cs.UserHomeImpl() which eventually returns a null reference.
On a IIS Web Server, it currently forces you to have Environment variables which when combined resolve to an existing folder which does NOT have to a have a git configuration file.
We detect that it the code is running under IIS and simply return a new FilePath instance constructed with a fixed folder path which means we have a no installation footprint other than installing Git.
Hope that helps.
from ngit.
I was actually thinking of eed3e5d , though after further examination the fix in that commit will not help in this scenario.
At the moment the win32 path checks for a bunch of env vars and if they are all null it tries Runtime.GetProperty ("user.home"). By default this is the same as the UserProfile special directory. What you could do is simply use Runtime.SetProperty ("user.home", "the_path_you_want_to_use"). This will allow you to override the default in a 'sane' way.
Would this solve your problem?
from ngit.
Yes it would work for us although would that not be a 'permanent' override? We were trying to ideally avoid breaking other runtime scenarios nGit provides by adding detection of the IIS context and then branching accordingly. This way it should (hopefully) work under more contexts.
from ngit.
You need something like this in your C# code:
if (running_in_iis)
Runtime.SetProperty ("user.home", path_to_use_as_home_dir);
from ngit.
Hi,
yes indeed that it was we are doing but just somewhere else (see earlier post). Is this something that can be looked into further for the best fix?
from ngit.
In pull request #31, I mentioned that for a normal Windows desktop user, environment variables HOMEDRIVE and HOMEPATH are used in NGit to determine the home directory. For ASP.NET user, the problem should have been resolved by b811c68 and 24e3cde.
I also found that passing ("C:", "\Users\User") to Sharpen.FilePath(string, string) constructor simply call System.IO.Path.Combine(string, string), which differs from the behaviour of java.io.File class in Java.
Should we either
- learn from Java source code to reimplement Sharpen.FilePath(string, string) constructor? or
- Patch NGit.Util/FS_Win32.cs to concat %HOMEDRIVE%%HOMEPATH% instead of calling Sharpen.FilePath(string, string) constructor? like what he did in https://github.com/sopolenius/ngit/commit/194291f5b8a5dbc549cab0690a7e27d065daa2cc
from ngit.
harry, the general rule for ngit is that we do our best to not patch the c# files to alter their behaviour. Every modification we make increases the burden when updating ngit from the latest java source. If your environment doesn't export the env variables that jgit requires, then realistically there are two approaches:
- Export the required environment variables before launching the process using ngit
- When your process launches, manually fix up the paths stored in Runtime
I don't think there is anything we can do from within ngit itself to fix this problem other than make a random guess as to what path we can use.
linquize, could you file a separate bug for this? We'll need to do option 1 there as there could be more than 1 place which relies on this behaviour.
from ngit.
For anyone interested I resolved this issue without setting any environment variables with little reflection:
var type = typeof(Sharpen.FilePath).Assembly.GetTypes().Where(ta => ta.Name == "Runtime").FirstOrDefault();
var method = type.GetMethod("GetProperties", System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.Static);
method.Invoke(null, null);
var field = type.GetField("properties", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Static);
var properties = (System.Collections.Hashtable)field.GetValue(null);
properties["user.home"] = Path.Combine(Path.Combine(HostingEnvironment.ApplicationPhysicalPath, "App_Data"), "git");
from ngit.
Why don't let it fallback (in FS_Win32 when all environment variables are null) to the FS class to get "user.home"? That is to use Environment.GetFolderPath (Environment.SpecialFolder.UserProfile) which already fixed in 24e3cde
from ngit.
Sharpen.Runtime is now public and exposes GetProperty/SetProperty methods which can be used to modify user.home (or whatever) at runtime. I hope this helps!
from ngit.
This doesn't seem to be the case with the version that comes packaged with ngit on nuget. is this package up to date?
from ngit.
I don't know who's involved in the nuget packaging nor how to update it myself. It's quite possible it's a very old version.
from ngit.
Related Issues (20)
- Cached RmCommand unavailable
- Clone, Fetch, Push documentation / examples HOT 1
- Basic authentication when cloning with http/https
- Ngit File locks HOT 12
- Cannot add HEAD to a bundle HOT 1
- Incorrect topological sorting HOT 1
- Ngit CredentialProvider - Keypair HOT 1
- Nsch - generating RSA key fails with casting exception HOT 1
- Compatibility issues with latest SharpZipLib
- Exception / hang on Mono.Security Diffie-Helman key generation for SSH Transport
- Cloning works on IISExpress but fails on normal IIS.
- IsClean() HOT 1
- Diff is duplicated
- CopyOnWriteArrayList is dangerously broken
- Code is outdated HOT 7
- Outdated ciphers for using JSch
- Port to NetStandard 2.0
- Object reference not set to an instance of an object.
- A secure connection could not be established
- Algorithm negotiation fail
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ngit.