|
I'm really happy and thank you....
Now i know it clearly..
|
|
|
|
|
This is bizarre!
I've got an app in C# that uses DirectSound. I set up the SecondaryBuffer in the normal way, using a WaveFormat struct. It runs fine on my machine and on other machines that have downloaded and installed the latest version of DirectX (DirectX 9.0c (4.09.0000.0904)).
However, on machines that show the exact same DirectX version number, when I run the program, if there is so much as a declaration that there is the slightest chance that I might possibly be considering using a WaveFormat structure, I get a file not found dialog box which tells me there was a "system.io.filenotfoundexception". Nothing in the detailed error report tells me what file was not found.
If I download and install the latest DirectX install, everything is fine. If I UNINSTALL DirectX from the machine, the program STILL WORKS!!! I've been comparing installed DLLs, looking for something that might account for the problem, but so far no luck.
I'm gonna get some pushback from my client if I tell him that all of his customers have to download and install the latest DirectX even if they already think they have it installed. Heck, I'd be pretty annoyed if somebody told me that! But, so far, that's the only solution I've found. I hope somebody else has run into this, or has an idea about tracking down the missing file.
In case it's not clear, all I have to do is have the following line in my code, and the program will not run on a computer that has not had DX re-downloaded and installed:
WaveFormat wFormat;
That's all it takes. And, as I'm sure many of you know, the WaveFormat structure has been around since before the last ice age, it's not something new.
|
|
|
|
|
What does the code look like that is building the path to the sound file?? Please don't tell me your' using CurrentDirectory or are just depending on a filename alone. You should be building a fully qualified path to the file using a known starting point.
|
|
|
|
|
Dave, here's exactly what it takes to get the error:
WaveFormat wFormat;
Nothing else. Nothing. Nada. Just that. Not even:
wFormat = new WaveFormat;
much less setting any of the elements of the structure. I added that line to another program that does nothing with sound, and that runs on every computer. Without the line, all is fine. With the line?
Ooooops.
Like I said, this is bizarre.
|
|
|
|
|
I was typing in a hurry before- to clarify, it doesn't matter if WaveFormat is public, private, or local to a function. Just saying I'm going to use that data structure causes the problem, but only on machines that have not installed the latest version of DX.
For perspective, I've been writing or supervising the writing of audio drivers and applications for 25 years. That doesn't mean I'm not doing something incredibly stupid- in fact I'd much rather find out it was a brain fart on my part as opposed to paging through lists of all the system DLLs on my machine and comparing them to a machine where the program fails. I just hope it's not something in the registry!
I tried a little drum machine program called winrhythm which, if I recall correctly, I found on an MSDN site. If I compile it on my machine and try to run it on one of the problem machines I get the same error. I also tried adding everthing including the kitchen sink to the references. It didn't make any difference.
I'm relatively new to C#, my first thought was that somehow I had not correctly set up the wave files (which are resources, not external files). I wish it had been that simple.
I did install the full DX SDK with redistributables on this computer, and as far as I know that has not been installed on the other computers. It seems likely that some file is installed in that process that is not installed on an end-user computer. If anybody has any suggestions as to which DLL information about the waveformat data structure is found I would greatly appreciate it!
|
|
|
|
|
Possibly (probably) a long shot, but are you installing a release or debug version when you get the problem?
I've run into similar errors, as the DX redist installs only the release DLLs. That usually generates a "Doh!" moment for me 
The actual DLL it's looking for will depend on whether you're using managed or unmanaged DirectX, and whether it's an X86 or X64 build, but have a look for "dsound.dll" in you Windows/System32 or SysWOW64 directories.
There are three kinds of people in the world - those who can count and those who can't...
|
|
|
|
|
Are you talking about release/debug version of DX or of the program I'm working on? In theory it's a release version of the program, although I have had questions about that since it's the same size as the debug version and is created in the /bin/debug directory. I moved the dsound.dll from my machine to one of the problem machines, with no joy.
How do I tell whether I'm using managed or unmanaged DX? I'm compiling for "any CPU", which I assume means X86.
I think I just had my "Doh!" moment- I should be able to define my own structure and use it. Hopefully C# won't be too outraged. Having cut my teeth on machine code it can be annoying to have a compiler insist it knows what I really mean, especially when it's wrong! But C# is pointer-based, so there is no inherent reason it can't take a pointer to a struct that is exactly what it wants instead of a system reference that doesn't work on some computers.
|
|
|
|
|
So much for the easy way. C#, the all-wise and all-knowing, must protect me from using my own identical structure...
I probably shouldn't go on a rant about C# on a forum full of C# users, but in my opinion it's better to learn how to write safe code than expect a compiler to take care of managing everything.
|
|
|
|
|
tjeffries wrote: Are you talking about release/debug version of DX or of the program I'm working on?
I meant your program. You'll be able to run a debug build on any machines that have the full SDK installed, but for machines with just the redistributable, you'll only be able to run release builds.
tjeffries wrote: In theory it's a release version of the program, although I have had questions about that since it's the same size as the debug version and is created in the /bin/debug directory.
That sounds suspicious. It should definitely be smaller, and be in the "Release" directory. I'd have a good look at your build options to check.
tjeffries wrote: How do I tell whether I'm using managed or unmanaged DX?
The managed interfaces are a bit different, although if you're accesing it directly from C# with something like "using Microsoft.DirectX.DirectSound" then it may be the managed version. The DLLs are different, and in a different place (which I can't remember t the moment).
tjeffries wrote: I'm compiling for "any CPU", which I assume means X86.
You might need to also check the build target in the project properties build tab. As well as the overall configuration, there's a specific target option hidden there (I sometimes forget it as well, and get bitten by it). Make sure this is set to X86, and not "Any CPU" or X64. That might be what you need to change...
tjeffries wrote: I should be able to define my own structure and use it.
It's possible, although the compiler might get picky about types and complain about it. If nothing else works, then it's worth a try...
There are three kinds of people in the world - those who can count and those who can't...
|
|
|
|
|
Right now the release/debug issue seems the most likely. I found the X86 tab, thanks, but despite the fact that the Build tab of the project properties windows says Release and the output directory is /bin/release, the program is the same size it is when built for debugging, and the files are put in /bin/debug. I thought the former might be some strange C# artifact, but maybe not.
Dumb question time- if I set the Build tab up correctly, click on "Clean Solution" (as far as I can tell, that just removes the exe, but maybe it does something else) and then click on "Build Solution" or "Rebuild Solution", it should build either a debug or release version depending on the settings, right? Is there something hidden away in a corner (or even in front of my eyes, so obvious that only a fool could miss it) that I need to do in order to get this to build the correct version?
Yes, the compiler got very upset at me for trying to do something so UNSAFE!!! as create my own structure exactly like the one Windows uses. Shame on me for even thinking of such a thing. 
|
|
|
|
|
OK, color me blind and not-too-bright. Just below the top menu bar there is the "standard" toolbar that specifies debug/release and processor. Changing the settings there has affected the file size and the directory it is written to. I'll see if it makes a difference in whether it works on a machine that does not have the SDK installed.
|
|
|
|
|
Nope, that didn't do it. I downloaded a utility called Exception Hunter and it tells me that DirectX.DirectSound is not installed on the problem computer. I think the best approach is to assume that's correct and put in some code to find out whether it's installed on the user's machine.
I assume that's in the Registry someplace? Does anybody happen to know?
|
|
|
|
|
tjeffries wrote: it tells me that DirectX.DirectSound is not installed
Hmmm, it should be installed as a normal part of the redist or SDK, so I'm not sure why it wouldn't be there.
A quick check on my machine shows it lives in "C:\Windows\Microsoft.NET\DirectX for Managed Code", although this is on Vista, so it might be slightly different if you're on XP. (My home machine is XP, but I'm at work just now.)
As a last resort you could always search under C:\Windows for all DLLs, and see if you can identify any DirectX ones - a bit of a slog, but I can't think of any other way at the moment.
The other thing to check is if it's in the GAC (C:\Windows\Assembly) although I've never found a way to back track from a GAC reference to the actual DLL location. There again, if it's in the GAC, it must be on the machine somewhere, I think.
I'll add an update later if I think of anything else...
There are three kinds of people in the world - those who can count and those who can't...
|
|
|
|
|
Thanks, that's very helpful. I was trying to figure out why a machine that could play other audio apps couldn't play this one, but the fact that it has to use a special "managed" version explains the problem.
Your help has been very much appreciated!
Warning- sarcasm ahead:
I can't possibly express how much I appreciate the way Microsoft has helped me avoid actually writing code for the last few days while I figured out how to work with their protection mechanisms. I can't imagine how I was ever able to write solid drivers that never broke in assembler and C.
/sarcasm
|
|
|
|
|
Hi
i'm looking for a way to improve .net app performance, i've used ngen.exe to perform this, but i didn't get good result.
can anybody help me about this issue ?
thanks
|
|
|
|
|
yes, assuming you provide full description and some code.
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
Hi Luc
i mean improvement startup time of .net app. can u help me (any way or tips to do this by ngen or other tools)?
|
|
|
|
|
There is no magic solution to performance problems.
Tools may help you in figuring out where the problem is, common sense should do that too (unless there are many people, and many component vendors involved).
Some tools may claim and try and improve performance a bit, IMO all too often what they do is try and remedy something that is basically wrong, and should be fixed, not softened up a bit.
Startup time is determined by:
1. the amount of code that needs to be loaded, rebased and organized; having lots of DLL files on distant servers would not help. Dynamically loading things, if and when required, could be a step in the right direction.
2. the amount of user code that needs to be jitted; occasionally splitting some huge classes in smaller ones might help.
3. the amount of user code that needs to be executed before the app becomes useful; not showing anything until a complex form full of database information is shown, would be wrong. A splash screen does not help objectively, it eases the user's mind though. Postponing operations whose results are not needed from the very first moment is always a good idea.
Furthermore, startup latency may be improved by all the measures that improve performance in general: not executing what is not needed, choosing appropriate algorithms, not making things unnecessarily complex, avoiding Forms with 50+ Controls, using efficient coding techniques, being economical with objects (e.g. not creating a new Font for every word on a Form).
And if CPU load is way below 100% during critical periods, using asynchronous operations and/or multi-threading judiciously will be a big help.
I always include logging code in my apps; my log shows major actions with current time, and outputs that to a text file; anytime two consecutive logs are more than 100 msec apart, I get suspicious and try and figure out why the app isn't moving forward.
In all, getting the right performance is part of software development, there is some science to it, and some art; it takes lots of common sense and experience, and no magic.
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
Depends - do you mean the startup time for .NET ( nothing you can do, really ), or your app ( it's kind of insane to ask that without showing us code )
Christian Graus
Driven to the arms of OSX by Vista.
"! i don't exactly like or do programming and it only gives me a headache." - spotted in VB forums.
I can do things with my brain that I can't even google. I can flex the front part of my brain instantly anytime I want. It can be exhausting and it even causes me vision problems for some reason. - CaptainSeeSharp
|
|
|
|
|
Thanks Christian
i mean startup time for .net apps (generally)
|
|
|
|
|
Adding to what others said, you can try using RuntimeHelpers.PrepareMethod to pre-JIT. This improves the load time. When a .NET application starts, you can always expect a small delay as CLR loads. In C++, you can use /DelayLoad:dllname[^] linker option to delay loading of a DLL. So it will be loaded the first time when it is used and this can improve the startup time. I am not sure the equivalent of this in C#.
|
|
|
|
|
1. Where would the call to PrepareMethod be? If it's in startup, it would slow things down even more.
2. MSDN[^] says that PrepareMethod "Prepares a method for inclusion in a Constrained Execution Region (CER) with the specified instantiation.". Nowhere does it mention that the method is JITted. AFAIK, CERs are created to make sure that certain code gets executed always in the face of errors, however critical they may be.
N a v a n e e t h wrote: In C++, you can use /DelayLoad:dllname[^] linker option to delay loading of a DLL.
That is how .NET works by default - assemblies are loaded only when a method referencing a type in an assembly is JITted does an assembly get loaded.
|
|
|
|
|
S. Senthil Kumar wrote: it would slow things down even more.
But I have an opposite experience. I can see slight changes when I used this.
2 - Yes, MSDN is not saying that methods are jitted. I got the idea from JIT methods at runtime[^] article. It worked well in my case.
S. Senthil Kumar wrote: assemblies are loaded only when a method referencing a type in an assembly is JITted does an assembly get loaded.
Yes. But the delay you are seeing is CLR loads not the assemblies you have used loading. We can even delay the loading of these assemblies. Read this[^].
|
|
|
|
|
N a v a n e e t h wrote:
But I have an opposite experience. I can see slight changes when I used this
I'm not convinced. I read the article you linked to and the author's response to your comment - he says he'll hide the initial delay by showing a splash screen. The author's idea is to take the JITting performance hit upfront rather than amortizing it over the running time of the application - there's still a performance hit. I haven't seen it in practice though.
N a v a n e e t h wrote: Yes. But the delay you are seeing is CLR loads not the assemblies you have used loading. We can even delay the loading of these assemblies. Read this[^].
Again, the article says this is useful if the startup code isn't doing pure unmanaged stuff. Only C++/CLI offers that ability, code compiled in all other languages will immediately require the CLR's services anway.
Interesting links though, thanks.
|
|
|
|
|
How fast is fast? You have to provide some metrics about what you have and what you're looking for.
only two letters away from being an asset
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
