I am just learning Blend/Silverlight/VS2010/.net/etc. I have a simple project that resides on a network drive. When I tell VS2010 to rebuild the project, I get the following error message:
------ Rebuild All started: Project: MySilverlightApplication, Configuration: Debug Any CPU ------
MySilverlightApplication -> H:\PRJ\VisualStudio\ExpressionBlend\Unleashed\MySilverLightApplication\MySilverlightApplication\Bin\Debug\MySilverlightApplication.dll
C:\Program Files\MSBuild\Microsoft\Silverlight\v4.0\Microsoft.Silverlight.Common.targets(214,9):
error : Could not load the assembly
file:///H:\PRJ\VisualStudio\ExpressionBlend\Unleashed\MySilverLightApplication\MySilverlightApplication\obj\Debug\MySilverlightApplication.dll.
This assembly may have been downloaded from the Web. If an assembly has been downloaded from the Web,
it is flagged by Windows as being a Web file, even if it resides on the local computer.
This may prevent it from being used in your project. You can change this designation by changing the file properties.
Only unblock assemblies that you trust. See http://go.microsoft.com/fwlink/?LinkId=179545 for more information.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
The project was not downloaded from the Web (I created it using Blend.) After doing some searching, I guessed the problem may be due to .net security settings. I issued the following command:
C:\Program Files\Microsoft Visual Studio 10.0\VC>caspol -m -ag 1.3 -url "file://\\p4dc\h$\*" FullTrust
in the hope that would solve the problem. p4dc is the name of the server machine, h$ is the administrative share for the h: drive on the server which in turn is mapped to the drive letter "H" on the local machine (\\p4dc\h$ is mapped to H in the local machine).
That did not solve the problem. I don't know if my caspol command is correct (I wasn't planning on learning caspol on the fly), it just seemed like a reasonable thing to try. The problem goes away when I make a copy of the entire project on the local C drive but, that "solution" is rather undesirable.
At this point, I don't really know what else to try to solve the problem without moving the project to a local drive.
Any help leading to a solution is much appreciated.
John.
The error message displayed by VS2010 would lead anyone to believe the issue is with trust and security and it is BUT, no amount of allowing full trust on the network drive will solve the problem.
What lead to the solution was first to port the project to VS2008 to find out if it would encounter the same problem. VS2008 was perfectly happy to run the project without complaint.
Then I converted the VS2008 project (which was working) to VS2010. VS2010 refused to build the project but this time the error message was different, referring to "remote assemblies" and to a link on MSDN, which led to the solution.
The real problem is that VS2010 considers an assembly on a network drive a "remote assembly" (the same as if the assembly were being loaded from a web site.) Caspol was not able to solve that problem (it seems it should have but, it may be my fault, I am not well versed in using Caspol).
To end this long story, the link provided in the error message is:
http://msdn.microsoft.com/en-us/library/dd409252(VS.100).aspx
after following the instructions in that link to edit "machine.config", I changed <runtime/> to:
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
the project built successfully and ran without a hitch.
Thank you to Alison and CodeNaked for their efforts to help,
John.
PS: it would have been rather nice if VS2010 had displayed the "better" error message initially. Instead, I had to port the VS2010 non working project to VS2008 where it worked and that one to VS2010 where I got the better error message that led to the solution.
Not sure if this will help but it's worth a shot: How Do I Allow my Visual Studio .NET Projects to Run from a Network Location?
Related
detailed message box texti made a winform application on my pc and it runs fine. but when I tried to run it on another PC by copying the exe file and other dll files there , the application failed to run and all of a sudden it shows a dialog box to close the aplication.
please refer to screenshot of error.
enter image description here
Like bassfader said: One possible explanation is that your application is handling files during startup. In that case: integrate more extensive exception handling for those parts. Potentially with logging, to locate the problem
In my experience this however is more often a case of missing some kind of dependency.
Double check .NET runtimes. Lookup the target .net version in Visual Studio and run the installer on the target machine.
Investigate if your app uses any assemblies that are not part of the .NET framework. Sometimes these are not copied to the bin directory if they are in the GAC (ensure the flag "Copy Local" is set to "Always" in Visual Studio)
Ensure you have copied the whole bin folder
Check compiler output to see if you've got Platform mismatches. IIRC this can sometimes work fine on a dev machine but cause problems when Visual Studio is missing or you get to a different OS.
Using Visual Studio 2003 Professional under Windows 7 SP1 (64 bit), compiling from the command line, I get a fatal error C1074: IDB is illegal extension for PDB file. The documentation on this error is sparse to put it lightly. The incredibly odd thing about this is that, utilizing the same build script on the same computer but under a different account does not generate this error.
My first guess was that something in the environment variables is causing this conflict, but doing a diff between them for the two accounts, and modifying PATH and INCLUDE to be the same does not fix the error.
Does anyone have a fix for this error, or any idea what actually triggers it? None of the files are being compiled with a /Z switch of any kind, so as far as I can tell, no PDB files should ever actually be generated (and on a successful build, no IDB OR PDB files are generated that I can see).
I was experiencing the same problem with solutions on Windows 7 x64 and Visual Studio 2005 Pro (SP1).
Symptoms
I am using Visual Assist X (currently build 2007). So in my case all I needed to do was to disable IntelliSense by renaming feacp.dl inside C:\Program Files (x86)\Microsoft Visual Studio 8\VC\vcpackages to something else. That fixed the crash at startup (probably unrelated to the issue the OP encountered).
After that the Debug configuration gave me loads of
fatal error C1033: cannot open program database ''
errors, one per file compiled by cl.exe.
With the Release configuration I got
fatal error C1074: 'IDB' is illegal extension for PDB file: <filename>
i.e. the one about which the OP was asking.
Solution
I found the solution more or less by accident elsewhere, reported for VS 2003. In a sense it's the opposite of Luke's answer.
Fatal Error C1074
This error has been reported to occur if the Windows 7 machines have
Windows XP compatibility mode turned on. To resolve the error, turn
off the Windows XP compatibility mode and recompile the solution.
Should you have other issues check the MSDN forums for more help. Its
not the source it sounds more like your settings with VS. I've never
run across this problem before so I'm little help.
That prompted me to check out the settings for devenv.exe (in my case under C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE). It looks like this:
In my case it was set to be compatible with Windows 2003 Server as depicted in the above screenshot. However, the compatibility must be turned off! (checkbox unchecked)
Also make sure to check out and correct the settings for all users by clicking the second highlighted button (UAC prompt will show up if you aren't already running privileged).
This solved the problem for me and I can avoid running VS 2005 Pro elevated all the time.
From information I've gathered on MSDN about issues similar, but not exactly the same:
Since it compiles with no other change than the user account, I believe there's a chance that it could have something to do with the user accounts permissions. Check and see the differences between the users permissions in VS's settings, and in Windows User Settings. The first thing I would try though is to close VS, reopen with Run As Administrator using the account that WON'T compile and see what happens.
In the attempt of sharing the solutions of some of my troubles, and in the hope of sparing them to others, I had the same issue trying to compile a legacy solution in VS2005/SP1 inside a Win8-x64 machine.
No matter what I tried to do, it always stopped there complaining about the illegal IDB extension...
On the other side, the very same solution compiled flawlessly in my previous Win7-x64 box, when run "elevated".
After much struggling I found that I had to use Win8 "Program Compatibility Assistant" (or whatever is named in the english version - my OS is using a different language) and tell it to run VS2005 in a Win7 elevated environment. After that, the obscure "IDB is illegal" error disappeared at once!
Hope this will help someone =)
After too many hours of research I have come up with nothing to solve this problem.
I am running a WPF program in an .xbap page file being hosted on internet explorer. Running the project in Visual Studio 2010 works just fine and generates no errors.
I want to be able to host the webpage on IIS 7.0 and to browse to it with a windows forms application. To test this I created a new website on port 80 in IIS manager. I then published the project to the local website folder and added the autogenerated project certificate file (projectName_TemporaryKey.pfx) to my Trusted Publishers and Trusted Root Certification Authorities.
My problem is this: whenever I try to browse to the file with internet explorer or with my windows forms program, the wpf program stops working. When pulling up the just-in-time debugger, I am informed that there is a System.ExecutionEngineException but am given no source code, no stack trace, and no data outside of an empty Dictionary enumerable. My guess is that this might have something to do with the database call made in the program to another machine, but I can't prove that.
I've tried several things to solve this including repairing my .NET 4.0 framework and altering permissions but nothing seems to be affect the error.
Does anyone know of a way to get more information on this error, or perhaps a step I may have missed when publishing this project?
Thanks very much.
Some things to check:
Windows event log often includes additional exception information (although usually in an awful format)
Output some trace information from your application so you can follow what's happening
Try attaching a debugger to the WPFHost and then stepping through the code
I have a WPF C# 4.0 Application. I was publishing projects fine before but all of a sudden one particular project starts to not publish. I get the following errors after a successful build.
Error 2 Could not find file 'obj\x86\Release\CSCDemo.exe'. CSCDemo.0
Next error is 'failed to Publish'
I know that CSCDemo.exe is in the Release folder because I checked.
Would Microsoft Visual Studio 2010 Service Pack 1 fix this?
The packager is looking at the obj\x86 folder, not the normal bin\release folder for your exe. I am thinking the issue has to do with either the packager looking in the wrong place or you have changed the project properties for your CSCDemo project. Have you changed it from being an x86 application to x64?
Another thing to try would be a complete rebuild.
I have just suffered from this problem. It seems my Avast Anti-Virus was deleting the file as soon as it was created. I just added my project folder to it's global exclude list and everything worked fine again.
I'm not sure exactly how your development machine can get fouled up this way, but this started happening for several developers in our group too.
After researching it, it appears that the built in build/publish script that Visual Studio (2010 in our case) uses has a flaw in the order that it does things. Most importantly it runs a cleanup on the OBJ directory deleting the target EXE file before the publish step can grab it.
The solution
This is somewhat of a hacky workaround, but it solved the problem for me.
The fix is to copy the file back to the /obj/ folder from the /bin/ folder right before the publish step. Unfortunately there is no way that I know to specify a BeforePublish event through the IDE, so you will have to edit the .vbproj file in a text editor.
Add the followign section just before the final </project> tag.
<Target Name="BeforePublish">
<Copy SourceFiles="$(TargetPath)" DestinationFolder="$(IntermediateOutputPath)" />
</Target>
change the platform from x86 to Any CPU will help
Build>configuration manager
change the platform against CSCDemo to Any CPU
I'm having an issue with VS 2010. It's running very slow and also crashes occasionally when compiling and packaging a xap file with the following error:
Xap packaging failed. Exception of type 'System.OutOfMemoryException' was thrown.
In the local Windows 7 temp directory \Users\usernamexxxx\AppData\Local\Temp
there are thousands of files, so I removed them and now VS is much faster.
Is anyone else having similar issues?
Yes, I have simmilar issue. when I clear My Temp Memory It works fine but after some time Temp directory is also showing some file.
and again the message comes "Out of Memory Exception".
It is an issue in Code. Your code is leaking memory. your code is not disposing object properly.
I haven't had that type of error message, but the thing that always seems to slow down VS 2010 for me is the .suo (Solution User Options) file. It basically keeps track of what files you have open, and your break points, but it is an always growing file. When it get's up to 5mb, it can take 20-30 seconds for VS to respond at times when adding a file, or deleting one from the solution.
I got tired very quickly of visual studio's slowness. My solution was to build everything on the command line using msbuild. I created a batch file which calls msbuild with my preferred options.
This option is actually really nice, because if you have a multi-core machine, you can pass the /m flag to msbuild, which will allow the build projects in parallel when possible (Visual Studio currently doesn't offer this functionality, but will in VS2012)
Calling msbuild is easy. For example:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\msbuild.exe MyApplication.sln /m
Then, if I want to debug, I just build first (on the command line), run the app, and attach the visual studio debugger manually.
I'm not familiar with this error in particular, but had an nasty issue back then with OutOfMemoryException during compile time for a big solution (more than 50 projects)
We used to circumvent it by using msbuild directly but debugging was a bit cumbersome
I checked on internet then and tried to extend the virtual memory that devenv.exe was using (by default it's 2GB).
Being on a 64bit Windows 7, the OS was already complying with the fact that an application could use more than 2GB.
Just had to fire up a command prompt and type :
cd\
cd "C:\Program Files (x86)\Microsoft Visual Studio 10.0"
copy Common7\IDE\devenv.exe Common7\IDE\_devenv.exe
VC\bin\editbin.exe /LARGEADDRESSAW Common7\IDE\devenv.exe
After a reboot, the compilation Exception was just a mere dream.
Note : I read afterward that Visual Studio 2010 was supposed to be Large Address Aware out of the box, so it shouldn't have "solved" my issue, but it did for me.