I am working on a game using the XNA framework. My game has several levels which I am storing the data in a plain old text file. In VS 2008 when I add the level file to the project and compile, I receive the following error message.
Error 1 Cannot autodetect which importer to use for "Levels\0.txt". There are no importers which handle this file type. Specify the importer that handles this file type in your project. F:\Projects\BrickBreaker\BrickBreaker\Content\Levels\0.txt BrickBreaker
The reason I am bringing this out is because if I change on of my levels and run the game, the level is not updated. I have found that the level is not updated because VS runs the game from the bin\debug folder and since the level files are not included in the project, they are not copied when they change. I also found that the platform sample that comes with the framework includes the level data in the project, that's where I got the technique from.
So, should I use a different file format or just deal with having to manually copy the new level files over?
Resolution - After digging into the answers on this post I found a solution. I added the text files to the project and set the build property to none. The error no longer occurs when compiling and the file is included in the project.
You can have Visual Studio just copy over the files if you want to the output directory. Under the properties of the text file in the project, choose Build Action: None and change the copy to output directory to as needed.
You can also check out the platformer sample. They use text files as their level format.
There is no content importer for text files. Ignore the content pipeline and just read the file in just as you would any other normal text file.
string line = string.empty;
using(StreamReader sr = new StreamReader("filename")){
while((line = sr.ReadLine()) != null){
//reads line by line until eof
//do whatever you want with the text
}
}
I had similar problem, and found it easier to have the files added to content project, and build action set to none, than to skip content pipeline altogether.
Related
I have created a C# windows application and after , and i have created my reports using crystal report .and it works fine ,
but now i need to upgrade my interface , so i have created another c# windows application , after finishing my application screens i need my old reports to be embedded on my new interface application ,
what i did was r.click on my application \ add existing item \ selecting the .rpt files ,
but when try to run my application and open the report , application raise an exception "Load Report Failed " .
The Inner Exception was "Unsupported Operation. A document processed by the JRC engine cannot be opened in the C++ stack" .
I have check these solutions :
report file path
rpt file property : Build Action as "Content"
rpt file property : Copy to Output Directory as "Do not Copy"
rpt file properties : Put Empty for Custom Tool and Custom Tool Namespace
Put application is still raise the previous error .
can someone help me to fix this proplem
Use runtime path for loadding report I.e
reportDocument.Load(Application.StartupPath + "\CrystalReport1.rpt");
Make sure report files are placed in specified folder which is directed by this path. use
string str = Application.StartupPath;
to be sure that which folder it refers to then place report files in this folder it will work fine. I faced similar problem like you and then I noticed this path indicates to bin\debug folder while report files in my project were somewhere else I just copied all files to debug folder and its working fine .... cheers
Crystal often gives you missleading error messages.
In my case I've set Copy to Output Directory of *.rpt file to "Do not Copy" (like you have it too) and I was passing the file path to the bin folder (where it doesn't exist) to ((ReportDocument)rpt).Load("[/bin/folder/path/report.rpt]");
->So check if the file(path) you want to load really exist
My Build Action is set to Embedded Resource (was default)
In my case, it was a problem with permission. Check if all users are allowed to access the file.
I have used one error handler code in my all vb6 projects,
Now I have to remove that error handler code which is in all sub procedures, functions.
I have to remove it manually all the time can it be removed automatically
I approached a task similar to this one time by writing a small program that would
1) read the project's vbp file and retrieve the names of all the files in a project
and
2) would then edit each of these files and make the desired changes.
Basically, I created a Visual Studio Installer project. I added a primary output to my project, which was great because it loaded in the dependencies and files automatically for me. The problem I'm facing is that I want to be able to mark my config file as a hidden file, but can't seem to figure out how.
When I go to View>File System it lists:
MyExternalAssembly.dll
Primary output from MyProject (Active)
So, is there a way to actually mark my config file as hidden during installation if I add a primary output project instead of the individual files?
I'm not sure if you really want to make it hidden. If you're worried about users looking at it, a more than average user will know how to un-hide things and pilfer around. So, that being said, if you want to keep users from seeing what's in the config you will need to encrypt the config. A good example of that can be found here:
http://www.davidhayden.com/blog/dave/archive/2005/11/17/2572.aspx
If you still want to hide the config, then you could try hiding it once the application is run for the first time.
Using: ApplicationDeployment.IsNetworkDeployed && ApplicationDeployment.CurrentDeployment.IsFirstRun with a click once application you can tell if this is the first time an application is run.
You could then use File.SetAttributes(path, File.GetAttributes(path) | FileAttributes.Hidden); to actually hide the app.config.
Which would result in:
if (ApplicationDeployment.IsNetworkDeployed && ApplicationDeployment.CurrentDeployment.IsFirstRun)
{
File.SetAttributes(path, File.GetAttributes(path) | FileAttributes.Hidden);
}
I've come across a strange behaviour in Visual Studio 2010.
When using embedded resources (files which are added to my C# project and for which the Build Action property is set to Embedded Resource), the files are included in the output assembly as binary data. Listing the resources is straightforward:
class Program
{
static void Main(string[] args)
{
string[] names = typeof (Program).Assembly.GetManifestResourceNames ();
foreach (var name in names)
{
System.Console.Out.WriteLine (name);
}
}
}
However, if the embedded resource file name ends with No.xxx (the extension is irrelevant), the file does not show up in the list. I cannot figure out any reason why Visual Studio 2010 would not include such a file. What did I miss?
Note: if I rename the embedded resource file in the solution explorer to something else, then everything works as expected.
Dan from the Microsoft Connect team has finally provided a valid explanation for this behaviour:
Hello, thanks for the report, this is actually working normally. The reason is that any resx files whose names match the pattern .VALIDCULTURE.resx are assumed to be specific to that culture. (This is how it has worked since VS2002, for better or worse)
In your case "no" is a valid culture (Norwegian, I guess) so the build process builds it into a satellite assembly. Here's what I got when I tried this. Note the "no" subfolder. If in your app you change your current culture to Norwegian, the resource load will load this set of resources.
So the problem has nothing to do with the word No itself, but rather with the fact that it is a valid, two-letter, culture name (in my case Norwegian). I checked, and indeed, there was a sub-folder in bin\Debug named No, containing a satellite assembly named Project.resources.dll in it.
Renaming the resource to end with .EN.xxx or .FR.xxx does, of course, exhibit the same behaviour.
As of MSBuild 16.9 you can include files like these by setting the WithCulture property to "false", as pointed out by #reduckted :-)
<EmbeddedResource Include="Resources.en.xml" WithCulture="false" />
I am trying to get the localization for my MVC project working with our existing infrastructure for editing string resources. We store all our resource string in database tables and have a front end web UI to edit them with, and an export application which generated the .resx files. This all works great, but I am having a little difficulty with a new project using MVC2 and VS2010.
I have asked another question on this, the answer to which almost got me there, but not quite.
I have now changed the resources to be in a Resources folder (instead of App_GlobalResources), as recommended by a number of people. And have the following settings against my .resx files ...
Build Action = Embedded Resource
Copy to Output Directory = Do not copy
Custom Tool = PublicResXFileCodeGenerator
Custom Tool Namespace = Resources
File Name = MyApp.resx
I have changed my export application to run the resgen.exe tool with the following parameters ...
string args = string.Format("/publicClass \"{0}\" /str:cs,Resources,{1},\"{2}\"", resourceFile, Path.GetFileNameWithoutExtension(resourceFile), csFilename);
... which generates an almost identical .designer.cs file as I get when I add the .resx file to my project initially. The only difference is the
The generated .designer.cs file differs slightly from the file I get when I run the resgen.exe tool from within my export application.
This is the code generated by VS2010 when I first add the .resx file to my Resources folder ...
public static global::System.Resources.ResourceManager ResourceManager {
get {
if (object.ReferenceEquals(resourceMan, null)) {
global::System.Resources.ResourceManager temp = new global::System.Resources.ResourceManager("Resources.MyApp", typeof(MyApp).Assembly);
resourceMan = temp;
}
return resourceMan;
}
}
... the difference when I run the resgen.exe tool is that is prefixs MyCompany.MyApp to the namespace in the constructor to ResourceManager
new global::System.Resources.ResourceManager("MyCompany.MyApp.Resources.MyApp", typeof(MyApp).Assembly);
Now, this to me seems to be a bug in the resgen.exe tool, because I've told it that the Namespace for my resources is Resources, not MyCompany.MyApp.Resources.
So, is there a fix/work-around for this problem?
The only thing I can think to do at the moment is to post-process the generated .designer.cs file with powershell and fix it!
Finally, I have solved the problem.
I decided to simplify things a bit by breaking my resources out in to a new assembly called Resources. I then added my resx files and set the properties for them as below ...
Build Action = Embedded Resource
Copy to Output Directory = Do not copy
Custom Tool = PublicResXFileCodeGenerator
Custom Tool Namespace = Resources
File Name = MyApp.resx
I then changed my export application to run ...
resgen MyApp.resx /str:c#,Resources,MyApp,MyApp.designer.cs /publicClass
... and to delete *.resources from the folder (created by the resgen.exe utility, but not needed)
This got rid of the prefix on the constructor to ResourceManager, and then i just added a reference to my new Resources assembly to my web application.
I've run a few tests to make sure all is good, including going in to the .designer.cs file and deleting one of the properties to cause a compiler error. Then re-ran my export app, and everything worked again.
So, I am a happy bunny!