I've been building a game for the past couple of days. After i've reached certain milestones i'll C&P the project folder into my dropbox folder then create a new one in my visual studio folder.
I've run across a problem now however where when i'm trying to read from files the streamreader is trying to read from the previous folders directory.
SO for example in 'Project2' the reader is trying to read from a file in 'Project1'. How can I change this?
First, you're most likely specifying an absolute directory ( "C:\Blah\BlahBlahblah..." ) or you've set the Working Directory to the wrong place.
Use relative paths or always store your data in a fixed place (the convention these days is to store your data is APPDATA. Storing it in a place like Program Files is a HORRIBLE CONVENTION. Don't do it when you release your program for realsies). Having tagged this with XNA, your root directory should also be specified to a relative place ("Content", "Data", etc.) so that when the executable boots up, it'll look in where the executable is, + inside the folder "Content" or "Data". That will make using the Content Loader easier.
Now, a general recommendation. You should never have to create a new project entirely to do version control. You're literally doing the work of any good free Version Control System (or like this one). Version control will make this much less painful for you.
Finally, a last tip for SO: describing your problem is cool, but what's even better than all of that is combined is posting the code that throws an error. Doing this allows us to figure out what exactly what wrong, because the skilled professionals of SO (of which I am trying to become one) have dealt with and know how to handle many kinds of exceptions and compilation errors (that, or our Google-Fu is stronk).
Related
I'm developing a desktop application for windows using visual studio. I'm programming in C# using WPF for UI.
I've googled looking for an answer, but haven't found any. Most likely because I don't exactly know what the actual problem is.
I've run into a problem where I'm trying to access a file in the folder resources
(C:\Users\MyName\Projects\MyProject\ProjectName\resources\xml\test.xml)
Using this code:
XElement xmlFromFile = XElement.Load(#"..\..\resources\xml\test.xml");
The issue is that the file is found and the xml can be accessed through the xmlFromFile variable, BUT the program also searches
D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\resources\xml\test.xml
The same also happens if I try this:
static string codePath = Directory.GetParent(Directory.GetParent(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location)).FullName).FullName;
FileLog log = new FileLog(codePath + "\\logs\\log.txt");
log.Log("Test")
Where codePath refers to the directory where the class files are, FileLog is a class that simply logs to a file using File.AppendAllText(path, string).
This piece of code gives the same error, but the path is instead:
C:\Users\MyName\AppData\Local\Microsoft\VisualStudio\15.0_919b9cb1\Designer\ShadowCache\logs\log.txt
But this one also writes the input string(test) to the correct file in the correct place. So why is this a problem if it works? While it works correctly here, the issue is that WPF does not give me a preview of the UI like it usually does, there's probably also other issues, but none that I am aware of. The preview simply states: Cannot create an instance of "Home". Where Home is a WPF UserControl.
So my question is: How to I fix the code so that the program does not search in both places(if indeed that's what it does)?.
What is happening here I believe is not that the program is not searching multiple places for a file, but the assembly from which the relative file search is being done is being loaded from different places. .NET has a fascinating and little understood mechanism for finding an assembly and loading it which is described in this document: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
So I think what is happening is that you are examining this behavior in different contexts (i.e. using the debugger, in the designer, etc.) and the assembly that is being used is loaded from a different place and therefore evaluates the relative file path differently.
So if I am right, then you are chasing a shadow. This is an artifact of behavior on your development machine which will disappear once the application is deployed and there is only one place for .NET to find the release assembly.
My application creates several text files that contain important data for its working. I am grouping up all these files in a folder. In Form_load() I gave Directory.CreateDirectory("C:\\xyz"), so that a folder is created in a drive which will later include text files, when the application will be delivered to clients. I want to see that the user does not delete or rename the folder. A dialog box that shows some warning message will be helpful. Is it possible with Directory.CreateDirectory()?
I think you should just warn the user about the importance of this directory. However, you can recreate the directory by performing this kind of check :
if(!Directory.Exists(path))
Directory.CreateDirectory(path);
From this point, you can imagine a mecanism that save the important files in a temporary way, and if the directory is deleted, you recreate it and put the previously saved files in it.
First of all, you might find reading this helpful.
Second: If I understand your needs correctly, what you want is much more painful than you think.
You should really consider doing what Damien_The_Unbeliever told you.
However, if you insist: You will need to use C++ (C# will give you and your users a lot of pain) for it, and you will need to "hook" SHFileOperation through something like ICopyHook. Start by taking a look at ICopyHook. It will be a lot of work and a lot of learning, and I don't think it's worth it, but there's the info. Good luck.
is there a way to get the version-history of a file if you only know an old name of the file?
I am currently looking at an old copy of our repository (I don't know the exact date, the copy was taken). When I compare it to the current repository, there is one file, that only exists in the copy, but not in the current repository. It has not been deleted in the repository. I guess, it has been moved or renamed. Is there any way in TFS to find the version-history using the old path and name?
I know that I could dig around using the name or some code-fragments. But IMO this is not an acceptable solution when using a repository :)
Thank you very much
Andreas
In Team Explorer 2010, you can simply turn on the "Show Deleted Files" option and navigate to the original folder, you'll be able to then see the file that was moved or deleted. You can view history on the item to see its last changeset - this will show you whether it was outright deleted, or if it was just renamed and thus the item no longer exists in the current path name (aka "slot") and was deleted that way. You can further drill down in to changeset details for that changeset to see the new path name (slot) that item occupies.
As you mention, you could certainly do this with a little bash against the TFS API using the GetItems method. Though I understand that it's not what you want to do, I thought it worth saying just because the TFS API is surprisingly easy to work with.
A couple of simple approaches (not already suggested in other answers) may help:
In your new repository, go to the folder that used to contain the old file, right click and show History. This will show all the versioned changes to files in that folder. Now look through the list of changes for files that no longer exist in the folder, and double click them to view them and determine if the file looks like an ancestorof your new file.
Or go for a brute force approach: get all the source code onto your disk and search for files of the same name, or files with some of the same text in them, as the file you're looking for (I'd look for comments that seem like they might be faily old and which use a distinctive wording that is unlikely to have appeared in many places. Comments are less likely to have changed than class/method names that might have been refactored if the file was renamed)
Grep may be an ugly, brute force way of approaching the problem, but sometimes it's the quickest and easiest. The TFS CLI tools are powerful, but unhelpful, complex and poorly documented, so unless you're already an expert, they can take a lot of trial and error to get them to do what you want.
This is really weird behavior, let's say I have an asp.net mvc project as follow on my desktop (vista):
/mvcapplication/app1
then over the course of development, I copy this solution to a briefcase on a thumbdrive so I can work on it from a laptop (xp).
When I insert the thumbdrive back on the desktop, I notice it's taking longer and longer to sync, eventually it took so long that it just hangs there. I checked the project structure and found that it is now:
/mvcapplication/app1/app1/app1/app1
with each /app1 containing the entire project structures. I am not new to visual studio, and I am sure I opened and saved the solution and files just as I normally did, but this is just bizzard. I thought this is caused by briefcase, but the same thing happened when I copied the solution into a folder on the thumbdrive.
I would have left this alone, but with that sort of crazy folder structure it's really difficult to determine which folder has my current changes..
Anyone ever run into something like this?
Never had this happen but then I don't use the Briefcase. Then again, I try to avoid most things in Vista.
I just use good 'ol copy and past for thumb drive stuff.
Alright, so I'm working on programming my own installer in C#, and what I'd like to do is something along the lines of put the files in the .exe, so I can do
File.Copy(file, filedir);
Or, if this isn't possible, is there another way of doing what I am attempting to do?
I wouldn't code my own installer, but if you truely want to embed files into your assembly you could use strongly typed resources. In the properties dialog of your project open up the "Resources" tab and then add your file. You'll then be able to get the file using:
ProjectNamespace.Properties.Resources.MyFile
Then you'll be able to write the embedded resource to disk using:
System.IO.File.WriteAllBytes(#"C:\MyFile.bin", ProjectNamespace.Properties.Resources.MyFile);
Honestly, I would suggest you NOT create your own installer. There are many many issues with creating installers. Even the big installer makers don't make their own actual installers anymore, they just create custom MSI packages.
Use Mirosoft Installer (MSI). It's the right thing to do. Make your own custom front-end for it, but don't recreate the already very complex wheel that exists.
UPDATE: If you're just doing this for learning, then I would shy away from thinking of it as "an installer". You might be tempted to take your "research" and use it someday, and frankly, that's how we end up with so many problems when new versions of Windows come out. People create their own wheels with assumptions that aren't valid.
What you're really trying to do is called "packaging", and you really have to become intimately familiar with the Executable PE format, because you're talking about changing the structure of the PE image on disk.
You can simulate it, to a point, with putting files in resources, but that's not really what installers, or self-extractors do.
Here's a link to Self-Extractor tutorial, but it's not in C#.
I don't know enough about the .NET PE requirements to know if you can do this in with a managed code executable or not.
UPDATE2: This is probably more of what you're looking for, it embeds files in the resource, but as I said, it's not really the way professional installers or self-extractors do it. I think there are various limitations on what you can embed as resources. But here's the like to a Self-Extractor Demo written in C#.
I'm guessing here, but if you are trying to store resources in your application before compilation, you can in the Project Explorer, right click a file you would like to add, chose properties and change the type to Embedded Resource.
You can then access the embedded resources later by using the instructions from this KB:
http://support.microsoft.com/kb/319292
in case you simply want to store multiple files in a single file storage (and extract files from there, interact etc.) you might also want to check out NFileStorage, a .net file storage. written in 100% .NET C# with all sources included. It also comes with a command line interpreter that allows interaction from the command line.