I have an scenario that I have to build my project and copy generated dll to another path.Because In our company every one builds his project and copy his dll to another path and IIS run all dll together as a single web application(we copy our dll by post build scripts).
But it takes me alot of time and for seeing every bit change I have to wait alot of time to build,copy,reset IIS(some time) and see my result.Is there any way to config Msbuild to build just part of my code that changed and I see my result in shorter time as like as debug mode in visual studio.In debug mode you change your code and msbuild can rebuild new changes and shows you just in time.
note : in development environment every one has a local IIS with compatible dll of others.
note : Because of some custom settings, no one can run his project in visual studio by run debug
I appreciate of any help
I have a predominantly managed c# .net 4.6 app that is trying to call into a c++ dll (that is also built as part of the solution), Visual Studio 2017.
I get this exception:
"System.IO.FileNotFoundException: 'Could not load file or assembly 'XXX.dll' or one of its dependencies. The specified module could not be found.'"
There doesn't appear to be any more information. The dll is in our binaries directory with all our other dlls that load fine, and the exe that is being run in the debugging session (The start up project).
I've checked the solution configuration manager, its building the dll as x64 in our Debug|Any CPU config, which makes sense.
No one else in the office has this issue, and I didn't have this issue on my old computer (I'm getting now trying to set up my new dev computer, which is the exact same specs as the old one) Windows 10.
I have the WindowsSDK 8.1 and 10 installed, and the vs c++ redistributes.
Any Ideas? Or atleast, and idea how I can get more info about whats actually going wrong? (This exception is frustratingly vague).
You’d want to use Fuslogvw.exe, the assembly binding log viewer. It can be started by launching the Developer Command Prompt for VS. The first thing is to enable logging, and the simplest way is to run as administrator (as a comment to an answer here correctly points out); you can alternatively set the ForceLog regkey specified here if running as a regular user account.
There's also a small video I did a while back to test how this works. You can find this in this article. Just scroll to the bottom, it's within the 2nd question starting from the end.
If that doesn't work, run Process Monitor and set a filter for your specific .dll and see what the CLR does in detail when searching for it.
I'm running my .NET 4.0 (C#) project in debug mode after I start VS2013. It runs just fine.
The second time I start it from VS, I get the Dialog box that says "Error while trying to run project: Unable to start program C:\path\to\file.exe"
The process is still alive in the Taskmanager when I dismiss the dialog box.
From Windows Explorer, I can run the program just fine. And after closing it, the process is gone too from the Task Manager.
A rebuild doesn't help.
Is this a common problem with a known solution?
I had an issue similar to this and I had to clear the component cache instruction can be found Here.
Hope this helps.
For my case, it cause by Platform target, you could force choose it to x86 or x64 which your project is:
Each Project's Properties > Build > Platform target
As I pointed out also here, the only solution that worked for me was to disable the ConEmu integration:
ConEmu → Settings → Integration → Default term → disable Force ConEmu as default terminal for console applications
Some users reported that it was enough for them to disable the Aggressive mode in that same settings tab; that wasn't the case for me though.
The topic is old, but this might help someone else.
So in my case I made a file in Visual Studio with .cp extension (accidentally deleted the last 'p') this made visual studio just "include" the the file and not mark it as a compilation unit, thus not compiling it, I looked the *.vcxproj file in a text editor and found out about this, so if you open the project file in a notepad or something just find your file at the bottom usually and change from <Item .../> to <ClCompile .../>
I was getting similar errors. I just had to restart visual studio. Sometime couple times a day.
I had a similar error and resolved it by cleaning the solution. Right-click the solution name in Solution Explorer and choose Clean Solution.
I found a solution here:
Please check "Use Managed Compatibility Mode" under Tools|->Options->Debugging->General.
I'm Brazilian, I don't speak English very well. I did this translation on google translator.
I know the topic is old, but it can still help someone.
I had this same problem in the following situation, I have a dual boot computer (linux debian 11 and windows 10). Inside debian, on my NTFS D disk, I created a folder to perform programming tests. After accessing that same folder with windows, I created a new project in visual studio inside that same folder that I had created in linux. The creation of the project went without problems, however when I tried to run the project (F5), I received the same error from this topic. I tried all the solutions I found on the internet, and nothing worked. I gave all permissions to my admin user and it still didn't work. Then I realized that even going straight to the folder where the application's executable was and clicking directly on it, I still received the access denied error message. So, I took the project out of the folder I had created in linux, and it worked. So, what I could conclude, is that because the folder where my project was was created in linux, for some reason, my windows didn't trust this folder, so it didn't allow running executables from inside that folder, even this one executable having been created by visual studio from within windows.
Just simply create a folder name as "projects" in c drive and copy paste the newly created project in it. Run the project by doing clean & Build or Rebuild method . It will work
open the folder which contains the solution in visual studio.
again, open your *.sln file by double clicking it inside the solution explore once opened try running the solution or rebuild the solution. once rebuild gets completed, it will open without error from next time.
My way of solving the error : error while trying to load project : Unable to start program and c:\Path\to\file.exe was simply by
First restart Visual Studio
Click the build icon
Select the rebuild option
Run the Program or Debug the Program
This was a weird one. Going to put what happened to me here because it might happen to someone else. Everything was fine with the app until suddenly after some fairly insignificant code changes I suddenly started getting this error. Visual Studio was compiling the executable just fine. But, the moment I tried to run it (either from Visual Studio or directly) the executable file would be automatically deleted right out of the Debug folder. Super odd--never seen anything like it. I began to get suspicious that perhaps an anti-virus or the OS was somehow identifying a checksum or some signature in the executable as "dangerous". Or perhaps some obscure compilation bug was corrupting the executable. So on a hunch I made another innocuous change (added a couple of lines of code to color code some text in a rich text box) and the problem went away.
I'm having the following 2 errors when trying to build on the build server:
path\to.NETFramework\Microsoft.Common.targets (3390): Could not copy "path\to\xxx.dll" to "path\to\yyy.dll". Exceeded retry count of 10. Failed.
and
path\to.NETFramework\Microsoft.Common.targets (3390): Unable to copy file "path\to\xxx.dll" to "path\to\yyy.dll".
The process cannot access the file 'path\to\yyy.dll' because it is being used by another process.
Locally, it's easy to fix - closing Visual Studio and running it as admin solves the problem. However, when using the build server (Microsoft Server), I can't seem to fix the problem.
Already tried restarting the build agent.
Made sure my project was the only one building at the time.
Manually deleted the dll.
Run the agent with the /m:1 argument.
Thanks.
EDIT: I've managed to reproduce the error locally. If I change the configurations in the configuration manager and clean->rebuild the project, it gives me the same error. However, like I said before, restarting VS solves this error, I just don't know how to do it in the server.
If you are using XAML build you could try to solve this problem via a setting of disable the parallel build in the build server.For TFS2010 and TFS2012 setting MSBuild Multi-Proc on the Process tab to False, for TFS2013, TFS2015 type the /m:1 in MSBuild Arguments. For more information about the /m argument in MSBuild, please refer to this document: MSBuild Command-Line Reference
Switching to single process builds has increased the build time, but if it's an acceptable loss. You could use this as a workaround.
Finally managed to find the solution. Turns out it had nothing to do with TFS itself. I wasn't able to reproduce the error locally because, for some reason, it was compiling when it shouldn't.
My problem was "broken references".
I am using some Biztalk programs and 5 of them had a dependency to other project (custom Biztalk Pipeline Components), but not the reference to the project itself. I think this maybe was caused by opening the components toolbox, although I'm not sure of it.
So, I manually removed and added again the references (Add->Reference) to said projects and now everything works like a charm.
I've been working on a simple project that uses some common .NET classes, isolated storage, some resources and no external libraries.
Somehow the EXE generated (either in debug or release mode) no longer runs (stops working as soon as it's opened) without giving any details or displaying any exceptions.
It runs normally in visual studio, and there's a .application in the same folder that when clicked starts in install process.
I'm not interested in installation files, I just want it to be the way it was: running an EXE (it's easier to get testers when all you have to do is running it).
I have previous versions of the program, and all of them run normally through the EXE's.
I don't recall changing anything regarding framework, deployment or build. I revised it and there's nothing changed apart from using new objects from the .NET framework.
--[Update]--
Just checked the event viewer. Event data "not available" and answer "not available".
This is a classic example of when a personal version control system would have helped. It would have automatically kept every version of your code including the one right before you made the change that messed up your exe.
Anyway to fix your issue comment out the majority of the code untill it atleast runs. Add a simple output statement just to make sure it is doing something. Then slowly add back in more code.
I suggest you to run your exe file in a consol (cmd.exe) to see if your application displays errors or exceptions in it.
Check the <YourAppName>.Exe.Config file.
Probably it is not well-formed Xml.
I'd start with removing the setup project from the solution, rebuilding then run it in debug mode.