Good day all,
I have written an application that i require to have a certain directory structure/. Nothing complex but it will need an "Images" Folder which contains two other folders "Temp" and "Complete".
These folders are in my solution however upon publishing all the folders are gone and i can not find any way in which to cause these certain folders to persist.
Will i have to write some code that checks if these exist and create them or can i make an application directory structure exist from the very beginning.
Dont know if this is relevant but i am using WPF and deploying through click-once.
Thanks,
Kohan
Regardless of whether you find a solution to the installation part of your question it would be prudent to check that the folders exist either on application start up or when you need to access them. After all, someone could come along and delete them without realising that they're needed. You might want to report or log this as an error, but recreate them anyway.
I assume you are using Visual Studio to create your ClickOnce deployments. If so, you can get around this issue by using MageUI instead.
Create your desired folder structure separate from you project's source code and bin folders. Copy in all the files you want deployed. Use MageUI and when you create the application manifest, point it to the root folder you created. It will take care of all the subfolders.
Also, I wouldn't worry too much about what ChrisF said. ClickOnce files are deployed to a very obfuscated location that users should never be in. And if they are in there deleting stuff, you'll likely have much bigger problems that a missing subfolder.
Related
I've been messing around with some public and work Git repos (all Github), as I grow my burgeoning C# expertise...
Especially for tutorial and course repos, they use a lot of folders. I also noticed you can add a "Solution Folder". However, I've also noticed Visual Studio has this love-hate relationship with folders, and sometimes they map to the physical folder, and sometimes they... just don't.
So - what can I use them for? Is there a good use case beyond just logically grouping files in a project to organize things a bit?
Oh! And one time I opened a folder from my drive directly in Visual Studio, and it showed up just like a solution - but it was just an open folder... it was kinda weird. What's up with that?
Links to Info
This Q&A (Actual folders in Visual Solution Explorer?) explains some more about how to keep folders in a solution mapped to the physical folders, which VS is very picky about and doesn't even try to keep in sync...
If I'm understanding your question correctly, there is essentially two most common uses for folders within your solution/project.
First and probably most obvious, folders are used to organize and group together relevant files. While this is more of a personal preference thing - I often use folders to organize my code similar to that of MVC (Model View Controller).
Second and usually less common but still something to be familiar with are folders that get copied into the output directory. These folders get created when you have a file with its advanced property Copy to Output Directory set to Copy always or Copy if newer. These files then become a part of the Build Action - upon building your solution, these files get copied to the output directory. This is used when there is a need for certain files within your solution such as a data file or external resource needed to interact with.
Example: I recently worked on a project that required my solution to interact with PhantomJs, which is an external standalone executable. I needed my code to make calls and pass data to this application - thus making it a vital part of my solution. PhantomJs was placed in a folder and set to Copy if newer which ensured my copy of the executable was an available resource during runtime.
Having created a WPF/C# demo application (in Visual C# Studio Express), what are the minimum files I would need to zip up, to give the source to someone? (Not deploy an executable, but enough actual source code to recreate the project).
Obviously I need the *.xaml *.cs *.sln *.csproj files.
Do I need *.suo *.csproj.user, or are those specific to my editor?
Do I need any or all of the files in the Properties directory? Some of those files say auto-generated, which would seem to imply they're not needed.
I'd share the Properties files as well, it generally being a good idea to share and version all files that are needed to compile the project regardless of the IDE. Since it's an IDE tool that generates those files, I'd consider it bad form to leave them out, in case you want to set up a Continuous Integration server or something of that sort.
The *.suo files are Solution User Options, which kind of implies that they're per-user, not per-project. Same goes for the *.user files.
the simplest thing is to delete any obj/bin directories (if they exist), and just zip up everything else.
the .user and .suo are things that will get recreated, but there's no harm in sending them (unless they are really big!)
That being said, it really depends on the details of your project, and how you have it organized.
I've built a winforms app (C#) that will take a list of file paths, and copy those files (from a different VS solution) to a new location (In a folder the user specifies) in the same directory structure they currently exist on local file system.
I use the Path class, Directory class etc and everything works wonderfully...except when it reaches a file path that points to a DLL.
The DLLs I am trying to copy are a part of the other solution, and that solution is not currently open.
I have tried restarting computer to make sure visual studio isn't somehow hooking into that DLL even after the solution is closed.
The DLL in question can be copied by regular manual means (i.e. copy and paste shortcut).
So short of creating a batch file in the program, and running xcopy on that DLL path, I don't know of a way to get this to work.
From what I have found from google searches (which isn't much on this particular situation), File.Copy() should work..
Any help would be wonderful, even if it is a link to a duplicate question I may have over looked.
Thanks!
-The error message is: The process cannot access the file [insert file path] because it is being used by another process (The path is definitely correct also)
-Just downloaded and tried to search for the DLL name with Process Explorer.. I also ran a similar exe from command prompt to no avail. It claims nothing is using it. That's why I am utterly baffled by this. Also, I just checked the permissions and everything looks great (i.e. Full Control, owner effective permissions)
-It does not handle open files. It basically build the correct src and dest paths and does a File.Copy() on those. How would I go about handling open files? I'm sure I could figure out if it was open, but what would I do it it were open?
It is not complaining about the file you're trying to copy, it is complaining about the file that you're trying to overwrite with the copy. Lots of candidates for that, virus scanners always get very excited about new DLLs, for example. Or it is loaded into a process, the typical failure mode for trying to implement your own auto-updater.
You can rename the target file to make your copy succeed.
Are you in vista or win7? If so, Check your 'User Account Control Settings'. Sometimes this can interfere with .NET security options and prevent file operations that would otherwise work.
As well as Process Explorer, I would use Process Monitor also from Microsoft so you can see what is happening at the point of failure and allows you to see if anything else is accessing the dll.
Possible culprits are
the program you are running,
your antivirus package
a virus.
If the path it is complaining about is the destination path, then is is possible that the path is too long?
Also, when using Process Explorer, make sure you have enabled the option to show details for all processes and not just your own.
I just ran into this issue as well. I tried copying a .DLL from an FTP server to a local directory (replacing the existing one) and for the life of me I could not get it to work. Keeps giving me an 'Access Denied code: 5' Error.
I then realized that the .DLL on the FTP server was not marked as hidden while the .DLL I was trying to replace was marked as hidden.
Once I changed the local one to also be visible. I had no more issues.
So my solution is:
Make sure both files are visible.
Hope this helps someone
I currently have a requirement where I need to validate that all the files in a folder structure which are in SVN to see if they are up to date. Is there a way to do this using the svn artefacts that are held in the same directory as the file without interacting with SVN?
Apologies, this appears to need some further explanation...
I'm iterating through the projects loaded within a solution and can access the corresponding files on the file system. I need to check
a) if corresponding files on the file system match the latest revision if the file is under source control and
b) if any or the files or projects have not been added to the SVN.
This is essentially a validation check prior to calling a build server to start a build in case a user has forgotten to check in some changes, new files or new projects to a solution. The build server retrieves the code directly from the source control.
Do you ask how to detect what files stored in SVN folder(s) are changed?
You ask to do that without interacting with SVN, but I would recommend avoid this because file or folder structure can be changed by Subversion team in future.
Try to use SharpSVN I use it in one of my projects. It handy, stable, has nice API and actively developed.
Also check comments in your question. Anyway you can check source code of SharpSVN to undestand how to make it by yourself
I am currently experimenting with TFS, and I really like it.
One small question, regarding test files:
I have a directory with some demo TXT, images, dirs... These are used during tests, so up until now, the path was hardcoded to a folder on my computer. Now I need to change this, of course, the TFS need access to the files too.
My idea was to place them inside the folder of my solution, I currently have roughly this structure:
Solution Folder
mysol.sln
SomeProjectDir
OtherProjectDir
_LIB for external .dll
_DEMO_FILES for test files
The whole solution folder is under source control. Would you do it the same way? How is the best and elegant way to get the "real" path of the folder for usage in unit tests? Using the execution path an cutting away the rest? Do test files belong under source control?
Thanks for any input,
Chris
EDIT: Beside the tip given in the answer, please be aware that with testing there are some pitfalls with this. The test is executed in a different folder (often named after some timecode), the testfiles do not get copied there automatically. Even if they are set to copy always.
The solution is to either add the files manually by using a attribute called DeploymentItem in the unit-test, or, in my opinion much better, adjust the Local.testsettings and add the folder there. Keep in mind, the folder itself will not be added, so you need to do it one level higher..
You will understand what I mean if you try it. Or search for DeploymentItem on google
test files are part of your project, so there is NO reason to keep them out of the version control system. You should commit to the version control system everything that is needed to build, test and run your system, including 3rd party libraries, config files, test files, and even arguably documentation. Please note that most of these things should be part of your Visual Studio solution as well.
In my projects usually I try to have all my resources as Embedded Resource, so that I don't need to figure out the path, they are compiled into the assembly. If for some reasons I can't go this way, I would make the build copy them to the output folder (so mark them as copy always in VS) and then use relative paths.