I was happy to find that upgrading to the new version of Smargit and removing the previous one, it still keeps my projects settings (as expected).
Yet, I did not found this setting stored in the users AppData folder. So, I was wondering where does Smartgit store project settings on Windows 7?
On all Windows platforms, settings are stored in %APPDATA%\syntevo\SmartGit\<version>, unless you have specified a different location by using -Dsmartgit.settings in bin\smartgithg.vmoptions.
Related
Is is possible to have a workspace (in VSC or any IDE) whereby said local project/folder contains 1 more or more sub folders that are cloud based (such as iCloud)?
I have a standard create react app "project" stored locally on my iMac (home) and when I need to use the same files on my work computer (macbook) I have either committed said changes (SourceTree -> remote) or taken copy via USB). Is there a way to sync just "some" folders to iCloud so that they are available from any location? (and also not break git/sourcetree)
Probable easiest to do the whole folder? and ignore \node_modules (like gitignore, nosync) perhaps?
my-app\
my-app\node_modules <- not this folder
my-app\public
my-app\src
The more I investigate this issue, the more it appears not to be possible in the context above, even using symbolic links and the .nosync file extn. :-(
I've developed an application for Hololens, so the only way I know to install the application in hololens is by visual studio, so I want an application package to be able to install without needing Visual Studio. I tried to follow this tutorial here
"https://learn.microsoft.com/pt-br/windows/uwp/packaging/create-app-package-with-makeappx-tool"
but I can not find these two .appx and .appxsym files.
If anyone knew, I appreciate that.
Maybe you know some steps, but I will go the full way (it's only deploying without visual Studio):
In Unity:
File> Build Settings
Choose Universal Windows Plattform (older Versions Windows Store). Make sure your settings are right (for hololens, sdk enabled...)
hit "Build"
Now you have to select a Folder to build. In my Projects I create just an "App" Folder
Once it is build navigate to this Folder (if it's not opening automatically).
Open the Solution (in the App Folder, not the Unity one)
In the Explorer right Click on the "Project Properties" which are named like your Project and Select "Store>create App Package (or maybe build, i got it on German)"
If you want only the appx File select "no" at the Windows Store question
Select an Output Folder and Version Number (count's up itself, newer numbers will overwrite older versions on Hololens automatically) and for Hololens only select x86 (the others are not needed. Just consume time). Now hit the "create"(again i hope i translate it right) Button.
Apply on Hololens:
Connect the hololens via USB (you can do it with wifi too, but not in our Network, so i never tried)
Open a browser and type "127.0.0.1:10080" so you get access to your hololens
Navigate to "System>Apps" and under Install App select the appx file (in my case under: (myUnityProject/App/AppPackages/myUnityProject/myUnityProject_1.0.0.0_Win32_Master_Test)
First time deploying select the dependencies (Dependencies/x86)
Hit "go" to Deploy (wait until everything is uploaded)
Some Notes:
To build the Apps i needed mvs 2015 installed (just installed), but this was before the Fall creators Update. Now newer Versions (should) work fine. Also I needed to install the windows "buildtools 2015"
https://www.microsoft.com/de-de/download/details.aspx?id=48159
Hope it works and have fun!
I am using a variation of Jeff Atwood’s Unhandled Exception handler it steps in when there is an Unhandled Exception in the application. It then logs the error, generates a screen shot and notifies the user.
When compiled in a solution the project generates an EXE that is called when needed. In updating the program I am using Visual Studio 13 to edit the existing settings items in the project properties. In the code I use commands such as this from ConfigurationManager.
string appProduct = unhandledExceptions.Properties.Settings.Default.AppProduct;
I was happy to see that it worked and reflected the changes I made in the IDE. However I couldn’t find the settings in the solutions generated confg file (MyApplication.exe.config). I assumed it was reaching back to the other project folder for the UnhandledExceptions.exe.config.
I created an installer and installed it to a virtual machine. My settings carried over, but again I could not see a config file.
It turns out the values are embedded in the executable UnhandledException.exe.
The project does not have any resources listed. Searching the web and StackOverflow looking a questions that want to do this, and there are a lot of them, it seems this was generally considered not possible and not desirable. Questions usually end in “You don’t want to do that, it’s called config for a reason”.
I may want to turn this off, so it is editable externally. The properties of app.config in both projects are identical.
What setting is making this possible after all? Is it a new capability with Visual Studio 2013?
There is no Visual Studio setting required. If you don’t want the user to have access to the configuration file, don’t include it in the distribution. One can always be added if the settings names are known.
In the description below application generically represents the name of the application being used.
I’ve found through observation some interesting things about the way ConfigurationManager works.
For User settings it will look in the following places in order of priority:
user.config for the application in the user’s AppData area
application.exe.config in the program folder
application.exe itself
Each setting is searched for individually. If your application requests a setting that is not found in either user.config or the application.exe.config it will get it from the executable.
For Application settings it looks in the following places in order of priority:
application.exe.config in the program folder
application.exe itself.
There is no equivalent to user.config for application settings.
Opening the application.exe in the Visual Studio IDE does not reveal a resource for the configuration information.
application.exe.config is handy because it can be modified externally and used as a default value for new installations. Once a setting is overridden in the user.config the value in application.exe.config is ignored.
The same is not true for the AppSettings section, the older configuration method from .Net 1.0. If I delete the configuration file it does not have them in the executable.
These observations were made with Visual Studio 2013 Update 4 and tested in Windows 7 Professional 64-bit. I suspect they are true in all versions.
I am having a ClearCase dynamic view on Win-7 Machine, I added the ClearCase View Shortcut (Created in Win-7 Machine) to an XP machine.
When I try to compile my project from view mounted in WinXP machine, it hangs, and it requires hard reboot. I tried many times, but I got the same results.
Is there anything to do with Anti-virus settings?
Dynamic views can be an issue when scanned by anti-virus: it is best to add m:\ (the mounting point for dynamic views) to the exclusion list of said anti-virus.
I wouldn't recommend accessing a Win7 dynamic view from WinXp, but rather define a dynamic view directly on the Xp.
1. check the clearcase version is same on both windows 7 and windows XP.
2. check if you can use that dynamic view, which created in windows 7, to mount vobs, set config spec, and view the files properly.
3. Check if all clearcase services are started properly.
4. apply the latest windows patch and clearcase patch on both windows 7 and windows xp.
If above checks are fine, I don't think the problem is related with anti-virus. I run clearcase client with anti-virus without issue, and I can mount the dynamic view on windows xp which created in windows 7.
Very simple Winforms application I want to deploy manually. Can all the referenced assemblies simply go in the application folder or where should they be published? (In ASP.NET they can go in the \bin folder). I would rather not put in the GAC.
By default I place the referenced assemblies in the same folder I deploy the app to (or \bin for ASP.NET), barring a Very Good Reason to deploy to the GAC.
You can use .NET probind to define a relative folder where the application should search .dlls at start. You only need to add a simple config file with your application.
For simple apps, I deploy the executable and the config file in the root directory, and place the needed libraries in a lib subdirectory:
/
|-MyApp.exe
|.MyApp.exe.config
|-lib
|-Lib1.dll
|-Lib2.dll
Use this link from a recent anwer to find out how to create the config file
Eric J's answer is probably the correct one, but there is a reason to be wary of placing the assemblies in the application folder: Windows 7. I haven't run into this problem personally, since I'm still in Vista Hell, but apparently in Windows 7 the Protected Administrator account (which you normally run under) doesn't have write access to all application folders - it only has write access to application folders that were installed by that user. So if your application was installed by a Windows XP or Vista user, and then that user upgrades to Windows 7, your default Protected Admin user will be denied write permission on the application folder (since it has a different SID under the new version of Windows).
This problem would only affect you if you try to upgrade the dependent assemblies, and it would only affect users who installed your application under an earlier version of Windows and then upgraded to Windows 7, so I don't know how big a deal this would be for you.
See this article for more details.