I've got a pair of IIS Express applications. One of these is extremely heavyweight (20+ second start time on development machines). One of these is extremely lightweight and just serves up scripts.
The problem is that when you build the lightweight application (to rebuild the scripts), IIS Express restarts both of them even though only one changed. I've confirmed that the C# side is actually not rebuilt as the C# did not change; so presumably it's actually a VS feature to do this?
Currently we use an external tool to build the scripts (Gulp) to work around this so you can build from the command line, but we need some MSBuild features so we wish to move back to exclusively MSBuild.
We discussed removing our dependency on IIS Express for the lightweight application that would mitigate the problem, but it turns out this is extremely complicated for us due to how the two interact.
Is there a config flag somewhere we can set which will tell IIS Express not to restart if the code for one application changes?
Turns out this was fixed in VS2017 - our C# side no longer builds, so IIS Express does not rebuild and everything is fine.
Related
Here is my problem:
I've created a little app to communicate with a server, nothing much particular. I'd like to publish it so I can give the app to my friends but after being published, I click the setup, it asks me to install, and after a few seconds, closes and nothing happens.
I've tried to "publish" the app with a Setup project, it installs and when I try to open the app, nothing happens.
I looked for solutions but nothing worked for me. Do you have any ideas?
The programm is under Visual Studio 2019, .NET 4.7.2
This could be related to different reasons, like lack of runtime ( .NET framework runtime ) on target machines or application behavior as well ( you did not tell much about it).
You could use some logging framework like NLogger or Log4Net to save in a log file at least critical errors and warnings so that you could see on target machine directly what the issues are.
in general if you properly used a setup project that should make sure your installer checks for dependencies like .NET runtime and also creates a desktop shortcut,
if you are publishing via ClickOnce you can easily specify in there to create a desktop icon and to include or download pre-requisites during installation phase.
Are you sure the issue is not related to exception handling and some failure happens when application started and tried to communicate with your server and for whatever network setting or reason fails to do so and then silently crashes?
If you try to connect to the server at the initialization of your program (form_load, etc.), it can happen when the connecting to the server fails. The whole application waits to reach a timeout, which may be 30 seconds long. Please check this scenario. See if the server is available and connectable.
I'm getting into ASP.NET, and I'm using MVC 5 to build my applications while I follow some Pluralsight trainings. I noticed that in the video training the instructor's Visual Studio builds really fast, but in my computer, after I modify something, every time I build it usually takes from 90 to 120 seconds for the build to finish and I be able to navigate through my application on the browser.
My laptop isn't super old or slow, since it has a Core i5 with 4GB of RAM and an SSD. I've tried to set the MvcBuildViews attribute to false, but still the problem persists. I'm using Visual Studio 2015 Enterprise with Update 2.
Any ideas on what should be the problem?
Delete everything under
C:\Users\YOUR_USER_NAME\AppData\Local\Microsoft\WebSiteCache
Check here too
C:\Users\YOUR_USER_NAME\AppData\Local\Temp\Temporary ASP.NET Files\siteName
It seems like it was a problem with Visual Studio 2015 Update 2. Once I installed Updated 3 it got way faster to build. I noticed that now the IIS Express isn't closed between builds, so now when I build my MVC projects I usually see the result on the browser in less than 20 seconds.
This is not much of an answer that will solve this problem for you. But, I specifically run into this issue with ASP.NET applications. With one of our solutions we have nearly 60 projects and that takes WAY to long to fully build and debug inside a browser from VS.
How I solved this was to point one of our servers with IIS to the folder that my presentation project builds too. This way when the web project is built I can browse my IIS website and see the changes. The downside to this is I can't actively debug in VS easily.
As far as speeding up VS to build this faster with debugging I have had no luck with my experience. From messing with symbol loads, just my code settings, VS IIS settings, but nothing has truly fixed this for me.
During our adventures of building a 'simple' API using WebAPI we've had our fair share of issues as any project does, however I am unable to find any such resource that can explain the following behavior:
Details :
Visual Studio 2013 with Update 2 (however, before updating, this was the same)
Windows Server 2008 R2
Web API 5.1.2
The issue seems to be related to the "Publish" command, specifically the "Precompile" option.
When running via IIS Express, we see no issues at all.
If we publish once, it fails to include the App_Global.asax.compiled & App_Global.asax.dll in the bin directory. If it is updating an existing instance of the application, it will actually delete the existing two files.
Note: This Happens regardless of WebPublish or FileSystem Publish
This behavior is causing 404.0 Errors upon loading to IIS, instead of our expected 201.
However, if I publish a second time no changes to the previous profile/configuration, it adds the two back.
For a while, we thought it was permissions issues, and weren't seeing consistent behavior. This happens on all of our development machines with the same behavior.
We've seen posts regarding mysterious behavior, but from our analysis, this is the root of the problem.
Just wanted to let everyone know that my problem was solved.
This was an issue with a virus scanner scanning the newly created temp directory for precompiling and actually locking the files in question.
So if anyone has issues such as this and is running any antivirus (especially enterprise level):
TLDR:
Check if your antivirus is locking files.
Turn off all compsec scanning utilities and turn on one by one to isolate which is causing problems.
I have been tasked with updating the companies outdated build process. It is all done in batch and perl scripts. The current build process is:
Schedule a build through a web interface.
Build server takes the build process off the queue.
Build server checks out all of the files from the TFS source control.
Build server runs a couple of code injection scripts that modify the source before the build.
Build server updates versions and signs the code.
Build server uses visual studio to compile the projects.
After that is finished the build server zips up the output and drops it in a network share location.
The real difficult part is the code injection scripts. They are 3 perl scripts that modify a lot of code. They are also very machine dependent in the way they were designed. (So I can't just drop them in the build process without a lot of modification)
My end goal is to be able to run the build process on local dev machines and also have CI running on the TFS server.
In my searching it seems that there is no way to emulate a TFS Build on a local machine. So is my only option to use pre-/post-build command line scripts in my cs.proj files? Or is there a better way to do complex builds on the local machine and run the same builds on the TFS?
I have seen Using TFS build definitions on a local machine, but that seems a bit hacky to me. I guess it wouldn't be a horrible solution if there isn't a better one.
I have tried to do something similar in the past myself. Unfortunately, there isn't a good way to go about it because of everything that the TFS Build Workflow requires. What I found was that there are basically 2 ways to go about it.
Create a MSBuild script that will run on both Server and Local
Create a MSBuild script for local and Custom Activity for Server.
If you are intent or have a requirement that you be able to reproduce the build exactly on both the developer machine and the build server, then I would opt for #1. Otherwise I would go with #2. The second option is nice because then you can play within the TFS workflow for doing the main builds which provides you with many objects that you would need as well as giving you a nice place to configure settings without having to check out/in files to change how the build occurs.
For either method you would most likely have to modify your Perl scripts to take in parameters to account for any customization you have to do between systems. Then you can have the user either pass these in or default them in the MSBuild script for local builds and set them up as parameters in the TFS Build Workflow. Thus they can be easily modified if needed. Regardless of the method though, the only good way to do it is to standardize on how things need to be setup on the developer machines and the build server so that you don't have to provide the customization as much.
If you do opt for the first option then you can use the Legacy build configuration for TFS build which supports using a MSBuild script for everything and then you can share the script between both developers and the build server but if someone accidentally changes this script then it does run the risk of breaking the build.
I have the source code for a C# project (which wasn't written by me) which I run on one of our servers.
There is a particular part of this program (a menu option) which occasionally fails silently and I can't figure out why from just looking at the source. (The part of the program that fails requires various features that are not on my development machine, so I can't test it on my own machine).
I would like to debug this program and in particular step through the code line by line. Since the server is outside our firewall, remote debugging feature will not work.
Is there any alternative other than installing Visual Studio on the server, ie are there any runtime debuggers that will show the C# source code and allow you to set breakpoints etc?
The project was written in VS 2008 and targets Framework 2.0.
You should be able to use DbgClr for a framework 2.0 app. It is a standalone graphical debugger that comes with the SDK. You will need to ensure that the PDB files, that matches the running build of the application, are available to the debugger.
That being said, if you have any option to punch a hole in the firewall, so you can use remote debugging, that would probably be the easiest way to go.
Of course, it would be best practice to setup your local environment so you can reproduce the bug and debug locally; but I can understand if there are reasons that might make this unfeasible.
Another option is to use WinDbg with the SOS extensions. It's an extremely light weight debugger that doesn't even require the .Net framework to be installed. It leaves much to be desired in the way of UI and has a steep learning curve. But once you get the hang of WinDbg it's an amazingly powerful debugging tool.