Afternoon all,
I have a very strange problem. When VS 2012 is open, compile times are very slow. This slow compile time is present when building via VS and/or directly via csc.exe from the command line.
To test: Create a folder with the following items:
A batch file (compile.bat) containing:
echo %time%
csc /target:library class1.cs
echo %time%
and a class1.cs containing:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace ClassLibrary1
{
public class Class1
{
}
}
Now open a visual studio command prompt. Navigate to the above folder and run the batch command, without VS open. On my machine, this takes approximately 10ms, perfect.
I now open VS 2012, open no solution, do nothing other than open the the application so that devenv is running.
Now repeat the test by running the batch file, compile time is now 10000ms (10 seconds).
I have checked the event viewer for anything that is happening when VS is open but not when it's closed, used procmon and filemon to look for file access and checked to see if VS is enabling any services when it is open, all without success/impact.
I have even tried uninstalling and reinstalling VS, this solved the problem for the first few builds but it then reoccurred. Restarting the machine has no effect. I have no plugins installed in VS.
My colleagues machines do not display this problem and they have the same setup. This is all running on a machine with 16gb ram, 64-bit win 7 and SSD.
Anyone got any clues?
I've figured this out. I believe it was the result of some malware. I diagnosed the problem with the following steps.
Download ProcMon (http://technet.microsoft.com/en-gb/sysinternals/bb896645.aspx)
Add a filter to ProcMon on process name: csc.exe
I then ran a compile from the command line, with visual studio open. It took around 10 seconds, way too long! Looking at the output in the ProcMon window, I noticed what appeared to be csc.exe pausing for 5 secs, once towards the beginning of the trace, and once towards the end. See the following screens:
Start:
End:
It appeared that a RegCloseKey to HKLM\SOFTWARE\Wow6432Node\5c28f8fbc6fe942 was causing csc.exe to wait for 5 seconds, twice.
RegKey:
I then decided to rename this entry (added _old to the end), I then recompiled....BINGO, it compiled in less than 30ms!
After studying the entries contained in this key and some googleing it turned out that this reg key was the result of some malware. I used the following guide to remove thte malware and now the problem is completely solved.
http://www.explosiveknowledge.net/main/2012/08/19/browsemngr/
Please be aware that the guide above doesn't contain the correct reg entries, I think the virus must have been tweaked at somepoint, I couldn't find the reg entries mentioned in the guide but simply deleted the ones I'd found.
Please note that the 5c28f8fbc6fe942 part of the reg key seems to be randomly generated. If you have this problem is might be different but the values contain within will still talk about "Browser Manager".
Hope this helps someone!
To understand your query we need to look into the concept of response file.
A response file is a text file that contains a set of compiler commandline
switches. When you execute CSC.exe, the compiler opens response files and uses any
switches that are specified in them as though the switches were passed to CSC.exe on the
command line. You instruct the compiler to use a response file by specifying its name on the command line prepended by an # sign. For example, you could have a response file called
MyProject.rsp that contains the following text:
/out:MyProject.exe
/target:winexe
To cause CSC.exe to use these settings, you’d invoke it as follows:
csc.exe #MyProject.rsp CodeFile1.cs CodeFile2.cs
This tells the C# compiler what to name the output file and what kind of target to create. As you can see, response files are very convenient because you don’t have to manually express the desired command-line arguments each time you want to compile your project.
When you install the .NET Framework, it installs a default global CSC.rsp file in the
%SystemRoot%\Microsoft.NET\Framework\vX.X.Xdirectory (where X.X.X is the version of
the .NET Framework you have installed).
The Visual studio 2012 uses this default response file for compiling the code.
Because the global CSC.rsp file references all of the assemblies.Referencing all of these assemblies could slow the compiler down a bit.
Related
I'm new to Mono - thought I'd give cross platform a try - my main IDE is Visual Studio and so the process of building applications through the command prompt is a bit foreign to me.
I was following the Mono Basics tutorial, and have gotten to the point where it says Winforms Hello World. I copied the code provided and saved it to a .cs file (on the Desktop).
I then opened up a command prompt and pointed it towards the Desktop directory. I ran the command:
mcs hello.cs -pkg:dotnet
And the result was:
The console told me that it was a CS8027 error but nothing else.
I have 3 environment variables that I added, with no fix:
PATH -> path to mono\bin
PATH -> path to mono\lib\pkgconfig
PKG_CONFIG_PATH -> path to mono\lib\pkgconfig
This happens whenever I try to use pkg-config.exe (tried to use pkg-config.exe --list-all but the same problem arose).
I've checked other answers/questions about the CS8027 error but the solutions did not help - it still crashes every time!
Had the same problem. I had all the proper VC++ runtimes installed, but still crashed.
pkg-config.exe references librares (.dll) that are compiled in different versions of .Net. Your PATH (or pkg-config itself) might be referencing a different version than the one the .dll uses, or not have it at all.
pkg-config is a short-hand anyway. I fixed it by explicitly including the .dll I'm referencing using the proper version of .Net for me:
mcs hello.cs -r:"C:\Program Files\Mono\lib\mono\4.5-api\System.Windows.Forms.dll"
pkg-config is built with a different version of MSVC to Mono itself. You need the 32-bit VC++12 runtime installed for it to work. That ought to be included with mono.msi, as per https://github.com/mono/release/commit/8394dcc254510977c3e654abf916a48c6c6894fb
If you check the Windows event log, under Applications, you might get more information on what didn't work.
I had this problem, could help some.
D:\Code\Mono>mcs hello.cs -pkg:dotnet
error CS8027: Error running pkg-config. Check the above output.
I needed to download the following DLL:s from https://www.dll-files.com/
libiconv-2.dll
libgcc_s_sjlj-1.dll
libintl-8.dll
libglib-2.0-0.dll
Put them in C:\Program Files\Mono\bin
All DLLs should be 32 bits even if Mono was 64 bits.
In my system the problem was the empty space inside the path of install and how that is managed inside of the pc files.
A workaround is to edit the pc files to change the prefix entry to the short path. In my system:
prefix=C:/PROGRA~1/Mono
instead of
prefix=${pcfiledir}/../..
I'm having an odd issue with Visual Studio Community 2015. My program runs correctly inside the Visual Studio Editor, and it also runs correctly when the Application .exe is double clicked in the bin/debug/ directory. However, when the Application is run anywhere else on the computer (including the Release directory) the program does not run correctly. I am definitely copying all of the Debug folder to the location of attempted execution so it's not because of that.
When I run the executable, a loading icon appears on the mouse, in Task Manager it appears as a process using about < 500K RAM and stays there until reboot. No window appears at all, and it is impossible to end the process once it has started, meaning it cannot be deleted.
I'm using .NET 4.5.2 primarily however I've tried 4.5 and 4.6 and neither fixed the issue (I've checked and I have all 3 of them installed). I also tried copying the System DLLs locally and that didn't fix the issue either. I also tried creating a minimalist solution (below) containing a project that only printed "Hello World" and quit.
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World");
Console.ReadLine();
}
}
}
This program experienced the same issues except it couldn't even be run within the Debug folder, only within Visual Studio. I then changed the project so it opened, then closed again straight away without printing anything so that it didn't use the System libraries at all, and it did the same thing. I then tried running the program in both 64 and 32 bit forced, (on a 64 bit laptop) and that didn't make a difference either.
I'm using Windows 7 Home Premium - Visual Studio Community 2015
Thanks for any help :)
Another possibility for such a rare issue could be your Anti-Virus program. Some of them like to inject an DLL into each created process to better protect you. But this can also lead to such awkward problems.
The only other way that comes to my mind would be to check the Event Viewer or run Process Monitor to get an idea where the error comes from.
Try using the release configuration and enable Break on all exceptions (Check Managing Exceptions with the Debugger for help on enabling the VS exception handling).
Hopefully this will break visual studio and show you enough information on the exception.
You can also try using Process Monitor to find the issue.
I would highly recommend using a simple hello world program to find out the root cause. My suspicion is on some corrupt .NET framework installation
That's because it's not the proper exe...
In order to get a proper working .exe for you App Right Click on your project in Solution Explorer > Go to "publish" tab > select Publish Now
(Now go to debug folder and find exe)
It will automatically open the "publish" folder which has files for install, but NOW go to your "debug" folder and you will find the working exe there and some other Visual Studio generated files releated to publish that you don't really need
~ ChenChi
I have developed an ASP.NET application using MVC, and everything has been going well, until I populated my Seed() method will the full dataset from the existing system that I am replacing (everything is fine with the cut down set I've been using for testing)
The Configuration.cs file is now approximately 2.5Mb and has around 4000 data elements being created in it.
With this large seed method I am getting the following error when I try and compile the application:
CSC : error CS0041: Unexpected error writing debug information -- 'Insufficient memory to continue the execution of the program.'
I can't find any examples of people having run into this issue before, any help from anyone who has would be appreciated. Also note that although the error refers to debug information, this happens on a Release build as well.
Running Windows 7 x64 with 12Gb of memory, 6Gb free while the compiler is running ...
Delete your project's .PDB file and try to compile again in Release mode. Else uninstall and re install Visual Studio. Deleting pdb files will mostly work.
Check this.
I am very new to C# and am wanting to write my code using a text editor like Notepad++ and compile using csscript. I have the two working and I am getting results from my code.
However, so far, I have only been able to run my code as interpreted, but I will eventually want to compile exe or dll files.
Am I able to compile my code into a standalone exe or dll using notepad++ and csscript, please?
Just an update for your original question...
CS-Script plugin for Notepad++ actually allows building normal executables that can be executed as any other managed exe.
Little too late, but here's the one that worked for me: I called this batch script bnr.bat (Build and Run)
echo Building project..
C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe /out:"%1\%2.exe" %3
echo Running project
%1\%2.exe
pause
Save this bnr.bat file and and then use NPP's Run and set The Program to Run as follows and before you press Run button, press Save and provide your custom shortcut keys:
<directory_where_you_saved_bnr.bat>\bnr.bat $(CURRENT_DIRECTORY) $(NAME_PART) $(FULL_CURRENT_PATH)
the $ constants are defined internally in NPP:
$(CURRENT_DIRECTORY) is the full path of the directory containing your C# file.
$(NAME_PART) is the name of your C# file minus extension (.cs).
$(FULL_CURRENT_PATH) is the full path for your C# file.
This does not have any error checking, but pause in batch script will allow you to see the errors and exceptions within the console before you exit the script.
I had set the PATH environment variabile, but somehow this batch script did not find csc.exe, because it was looking at the npp bin directory.
For .NET 5+ (and .NET Core), you can compile your project using the .NET Command Line Interface (CLI)
The command
dotnet publish
creates the files you need to run your program.
No, you will need a compiler (Microsoft´s from VS or Mono)
csc.exe is what you need. It should be at C:\Windows\Microsoft.NET\Framework\v4.0.30319.
Here is a link to a reference. http://msdn.microsoft.com/en-us/library/2fdbz5xd.aspx
And check out Visual Studio express, it makes life easier.
Thanks for the reply.
I have Visual studio but the license expires in 7-days.
I am using Notepad++ with an add-in called cs-script. The add-in checks and runs code in a similar manner to Visual studio but it will not compile an exe or dll file.
However, to answer my own question and as suggested by quarksoup, the answer lies within the csc comiler. By using the /flags, I am able to compile my programs from the command-line. I shall write a batch file that will do the work for me.
Regards
I am working on a Setup program which creates a .msi file. There is a CustomAction program associated with it which is written in C#. There are three COM object references made in this CustomAction program which are necessary in order for it to work. They are as follows.
Active DS IIS Namespace Provide (C:\Windows\System32\inetsrv\adsiis.dll)
Windows Script Host Object Model (C:\Windows\System32\wshom.ocx)
NetFwTypeLib (C:\Windows\System32\FirewallAPI.dll)
As added information, following are the tasks I use these DLLs in my program for.
To set MIME settings for a particular file type.
To create a desktop shortcut to a folder.
To register a program as a firewall exception
.
Now, here is my problem. When I rebuild the C# program and execute the CustomAction program from within Visual Studio, it works fine and I can get the above three tasks done like a charm. However, when I actually build the .msi and try to execute it and install the program on my system, it gives an error. I'm using a Japanese OS so it gives the error in Japanese so I'll try to translate the error message in to English as best as I can. The error is something like this:
*
File or assembly 'Interop.IISOle,
Version = 1.0.0.0, Culture = neutral,
PublicKeyToken = null', or one of its
dependencies could not be loaded.
Cannot find the file specified.
*
This particular error message is given because it relates to the first dll (adsiis.dll) because it is the one which contains the IISOle namespace. Similarly it gives error messages relates to all the three COM objects which I made references to from my program. Now what I can understand from this is, somehow when this code is inside the .msi file it cannot find the appropriate COM objects. I'm really confused why this happens as the Setup gives the same error when I try to install the program even on the same machine which I used to code the CustomAction. Funnily it executes flawlessly from withing Visual Studio Interface. Please do help me with this. Thanks in advance!
Note that I'm working on Windows Vista Business, but I need my Setup to be able to install on a variety of Windows OS ranging from Windows Server 2003 to Windows 7.
Just encountered this today. Go to "Turn Windows features on or off" and scope out everything under IIS, including the IIS 6 stuff.
Make sure that the feature "IIS Metabase and IIS 6 configuration compatibility" is checked, found under "Internet Information Services" > "Web Management Tools" > "IIS 6 Management Compatibility".
Anton, finally I found out what was wrong.
When I reference, for instance, dsiis.dll then Visual Studio places an Interop module, namely Interop.IISOle.dll inside the bin directory of my CustomAction program. Which is where the CustomAction.exe can also be found. It does the same process when I reference the other two COM objects; wshom.ocx and FirewallAPI.dll. But my actual setup program which is written using Wix copies this CustomAction.exe to some other directory and the .msi uses that particular CustomAction.exe file. The problem occurs since Interop.IISOle.dll (and the others as well) cannot be found there. (The error message said what I needed to look for from the beginning it seems; I was foolish not to look for it but thinking there might be bigger problems)
So this is what I did. I instructed the Wix project to copy those Interop DLL files to the same place where the CustomAction.exe which is used by the installer resides. That solved the problem so easily.
I'm totally a newbie when it comes to Wix, plus we needs to use the CustomAction for 2 and 3 because of some reasons.