2015-02-11 6 views
3

я столкнулся очень странный вопрос:как получить папку данных приложения 32 битные из 64-разрядных приложений на 64-битной машине с помощью C# код

Я получил 64 битные C# .NET приложения на 64 битом Windows Server 2008 машины R2 с и он запускается службой Windows и запускается под пользователем Local System User. Кроме того, это 64-битное приложение C# .net запускает 32-битное Java-приложение, и это Java-приложение имеет папку данных приложения для C: \ Windows \ SysWOW64 \ config \ systemprofile \ AppData. 64-битное приложение C# .net имеет папку данных приложения для C: \ Windows \ System32 \ config \ systemprofile \ AppData

Итак, для 32-битной прикладной папки данных приложения (в случае использования локальной системы User): - C: \ Windows \ SysWOW64 \ Config \ systemprofile \ AppData

и для 64-битных папку приложения приложения данных (в случае локальной пользовательской системы): - C: \ Windows \ System32 \ Config \ systemprofile \ AppData

Обращаем ваше внимание, что это не ошибка ввода, которую они ссылаются на противоположные папки (это решение Microsoft для 64-разрядной ОС), вы можете прочитать https://msdn.microsoft.com/en-us/library/aa384187.aspx для подробного объяснения.

Теперь мне нужно написать несколько файлов в 32-битную папку данных приложения из 64-разрядного приложения, так как эти файлы будут использоваться 32-битным Java-приложением.

Итак, мне нужно знать, как я могу получить 32-битную папку данных приложения из 64-разрядного приложения, используя C# .net.

Важное примечание: эта проблема возникла бы при запуске приложения под локальным системным пользователем (то есть приложение было запущено службами окон), и не будет никакой проблемы, когда пользователь явно запускает приложение beacause в этом случае , папка данных пользовательских приложений будет одинаковой для 64-битного и 32-битного приложений.

+1

«это ошибка от Microsoft для 64-разрядной ОС» - это не ошибка *, это продуманное дизайнерское решение. –

+0

может быть позволено исправить мое заявление –

+1

Почему вы не используете ** Environment.GetFolderPath (Environment.SpecialFolder.SystemX86) ** и ** Environment.GetFolderPath (Environment.SpecialFolder.System) ** для 32-битных и 64-битных данных приложения путь, а затем добавить config/systemprofile/AppData? –

ответ

0

Вы используете ключевое слово "shortcut" для указания каталога appdata, например% APPDATA%? Не могли бы вы использовать прямой путь, например, @ "C: \ Users \% username% \ AppData \ Local"

+0

Папка данных приложения локальной системной учетной записи находится не в C: \ Users. –

0

Сначала вы проверяете, действительно ли вы выполняете 64-разрядный процесс на 64-разрядной ОС. И если это так, вы сами строите путь. В противном случае вы можете просто получить системный путь и добавить целевой путь.

String path; 
//detect if the current application is 64 bit and running on a 64 bit system 
//NOTE: needs .NET Framework 4 to work 
if (Environment.Is64BitOperatingSystem && Environment.Is64BitProcess) 
{ 
    path = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Windows), "SysWOW64"); 
} 
else 
{ 
    path = Environment.GetFolderPath(Environment.SpecialFolder.System); 
} 
//append your target path 
path = Path.Combine(path, @"config\systemprofile\AppData"); 

Пожалуйста, обратите внимание, что при использовании EnvironmentIs64BitOperatingSystem и Environment.Is64BitProcess требует, по крайней мере .NET Framework 4.-

+2

Это зависит от деталей реализации, поэтому в будущих версиях Windows это может нарушиться. –

+0

Действительно, 'SysWOW64' является деталью реализации, но в будущем это не изменится - если вы посмотрите на свой каталог' System32', вы увидите, почему. Он должен быть назван 'System64' в 64-битных версиях Windows, но из-за совместимости с предыдущими версиями это не так. –

+0

Если вы не получили это в письменной форме, вы не можете рассчитывать на это. Хотя папка syswow64 вряд ли будет переименована или удалена в обозримом будущем, нет веской причины, по которой я знаю, почему локальный системный профиль должен находиться внутри этой папки. Стороннее программное обеспечение не должно использовать эту папку в любом случае, и я не знаю о каких-либо крупных программных продуктах, которые делают, поэтому обратная совместимость вряд ли будет серьезным ограничением в этом случае. О, шансы в вашу пользу, но ИМО такой вид игры подходит только в том случае, если нет другого выбора. –

1

Самое простое решение для восстановления приложения C#, как 32-бит, или использовать 64-битный Java.

Если вы не можете этого сделать, создайте 32-разрядное приложение, которое ничего не делает, кроме поиска пути данных приложения и запускает его из вашего приложения C#. 32-битное приложение может быть написано на C, C# или Java.

+0

нет ничего другого, что я мог бы сделать с самим кодом ... Потому что, первое два решения, я знал, и была какая-то причина. Поэтому я не мог пойти с ними. Более того, запуск 32-битного приложения - это правильно? потому что мое приложение будет вызвано службой wcf, и было бы так много экземпляров приложения, как это было в случае вызова. –

+0

Поскольку у вас уже есть отдельный экземпляр 32-разрядной Java для каждого вызова, запуск другого 32-разрядного приложения вначале вряд ли сильно повлияет на производительность. Но вы можете кэшировать результат, если хотите оптимизировать вещи. Один из способов - поместить его в реестр; если вы создадите раздел реестра с REG_OPTION_VOLATILE, он исчезнет при следующей перезагрузке системы, что гарантирует, что кэшированные данные не станут недействительными. –

 Смежные вопросы

  • Нет связанных вопросов^_^