I've been using RedGate's ANTS Performance Profiler for a while now. We recently updated our 3rd party dlls (Telerik) to their .net 4.0 version. When we did this, I no longer can profile our code because as soon as I hit a Telerik control I get:
System.Security.VerificationException: Operation could destabilize the runtime.
I spoke with RedGate and they told me, "Basically it's all down to Microsoft and their changes to CASPOL. ANTS has more features and these features require high privileges so that ANTS can read metadata out of assemblies in the running environment..."
Their suggestion was to run the process in full trust mode. How do I do that?
I've tried making adjustments to our Assembly.cs file, but since the problem doesn't seem to be generated from our code, there's not much I can do in terms of adjusting code.
P.S. Our app is a WPF/Winforms desktop application. I've found solutions for web apps by making changes to the web.config, but I can't really seem to find an equivalent solution (or understand it if it exists).
Related
I used Flexera's InstallShield Express to bundle my software into a Setup.exe file. I included .NET Framework 4.7.1 redistributable (2. Specify Application Data > 'Microsoft .NET Framework 4.7.1 Full' is checked and highlighted in middle panel, and says 'installed locally' > 'Install before feature selection' is checked on bottom panel).
I went onto my fresh installed Windows 7 computer with no internet access and attempted the install. It gave me the error:
"An error occurred while downloading the file
http://saturn.installshield.com/is/prerequisites/Microsoft.NET Framework 4.7.1 Full.prq"
I then connected to the internet, and it was able to go through. I looked for a text of the prq. There may be a way to find it thru InstallShield, but I found a forum post from community.flexerasoftware.com asking about 4.7.2.
The two parts of interest are:
<file LocalFile="<ISProductFolder>
\SetupPrerequisites\Microsoft .net\4.7.1\Full\NDP472-KB4054530-x86-x64-AllOS-ENU.exe"
URL="https://download.microsoft.com/download
/6/E/4/6E48E8AB-DC00-419E-9704-06DD46E5F81D/NDP472-KB4054530-x86-x64-AllOS-ENU.exe"
FileSize="0,0"/>
and
<properties Id="{BFF4A593-74C5-482F-9771-7495035EBBB0}"
Description="This prerequisite installs the .NET Framework 4.7.2 Full standalone package."
AltPrqURL="http://saturn.installshield.com/is/prerequisites
/Microsoft .NET Framework 4.7.2 Full.prq"/>
The fact that the file reads '4.7.1' is another can of worms I need to explore (not in the scope of this question). I'm assuming all prq files have a common structure. I believe that this information tells me the URL (download.microsoft.com) was skipped and the AltPrqUril (saturn.installshield.com) was used during my install. But even if the URL were not skipped, it would still looking at a page on the world wide web.
Question
Why do I need internet connection? The 'Full' version is specifically different from the 'Web' version in that you do not have to connect to the internet to install it.
Avoiding Internet Connection Requirement
To embed runtimes in the setup.exe and hence avoid the need for
an Internet connection, you can try to set the option "Extract
prerequisites from setup.exe" in the setup.exe tab in the
Release view as illustrated in the second screenshot below.
Then you select the "Full" .NET Framework version in the
Prerequisites View. Not 100% sure what features the Installshield Express version has vs the full versions. The below is from the Premier version.
You can check your finished bundle, by doing a "setup.exe /a" -
from a command prompt - on the final
setup.exe and extract the files to see what is really included in the bundle.
Quick Reminder
I think you should generally call Installshield support if you have a support agreement, or check their own community at: https://community.flexerasoftware.com.
Just mentioning this since people sometimes forget to check whether they have support agreements and support & community might resolve your problems in 5 minutes - if you don't get answers here.
Release Wizard
However, just shooting from the hip I would propose that the cause could be this setting that is available in the Release Wizard in the regular version of Installshield 2018. It is probably similar in the Express edition:
In the Release property pages, it seems this setting is under the Setup.exe tab and it is called "Installshield Prerequisites Location":
[
Prefer Download
For what it is worth I really dislike old, outdated runtimes included in bloated setups. This has to do with my experience as a corporate deployment specialists where much of the day consisted of extracting outdated runtimes from vendor packages.
I would always suggest you download very common runtimes from the web, or allow them to be installed via Windows Update. That includes basically all Microsoft runtimes.
I only like to bundle runtimes if they are 1) Rare and special, 2) Stable and well tested, 3) Small and well-behaving. Even then I would prefer them downloaded and installed separately - to allow security fixes to be installed without rebuilding your whole setup - you just put up the new runtime version on your server (marketing will want a new build for physical release - that is just added risk if you ask me).
War story: the SOAP merge module - back in the day - almost destroyed my package with global deployment scope. Deployment errors quadrupled. Prerequisites can really ruin your work, and you will face little understanding for the problem seen. Try to make it clear what breaks and why. And get rid of all prerequisites you can (pie-in-the-sky thinking, I know). Certain runtimes are unavoidable of course. I just ramble on :-).
we made one application on Visual Studio 2008 , it about to release. but now we are getting the crash while launching the application . could you please any give a suggestion how do i debug on this particular issue
You can run the Release build in the debugger, too. Turn on debug-info settings in both the compiler and linker tabs (I think that was not the default in vs2008 and there were two distinct places to set) but don't change any optimization options or other setting.
Then launch the program from the debugger. If the resulting EXE shows the crash when run normally but not when started via the debugger, there are more things to make the situations work the same (and that shows clues as to what is wrong, too). So let us know if that still doesn't reproduce.
There could be a lot of reasons for your application's Release is crashing.
Did you link proper Release libraries with your application in Visual Studio project configuration ?
Check your code for some missing Release specific code.
My best guess is you are not linking to proper libraries for the Release version of your application.
Also, one reason could be that your application may be trying to load some file that may not exist. This happens with me sometimes when my Release build of application does not find file that it needs (Eg: OpenGL application trying to load a shader file that is missing); and you don't check for errors.
I want to know the benefit of pre-JIT compilation (ngen.exe). What is the role of the Native Image Generator (NGen) process and why is it required?
Please provide an example.
For code execution on the .NET platform, the Common Intermediate Language (CIL) representation needs to be translated into machine code. If this happens immediately before execution this is referred to as JIT (Just In Time) compilation. Output of JIT is not persisted so your managed application has to go through JIT for every launch.
Alternatively, you can use pre-compilation to reduce startup overheads related with JIT compilation. NGen performs pre-compilation and keeps the native images in a native image cache. Then applications can run with the native images and may experience faster startup time due to reduced JIT compilation overhead. Initially, NGen was an install-time technology, developers made application installers issue NGen commands to trigger pre-compilation during install time. For more details, check out NGen Revs Up Your Performance with Powerful New Features. This article provides an example application that leverages NGen.
With Windows 8 (.NET 4.5), a new NGen mode: "Auto NGen" has been introduced. Basically, the .NET runtime generates usage logs for managed applications. When the system is idle, an automatic maintenance task runs in the background and generates native images. This way developers no longer have to deal with NGen explicitly. Note that this feature is only enabled for .NET 4.5+ applications that target Window Store or use the GAC. Here's an MSDN page that may be helpful:
Creating Native Images
And this is high-level overview of NGen and related technologies:
Got a need for speed? .NET applications start faster
Lastly, .NET framework libraries themselves use NGen for better performance. When .NET framework is serviced, some of the native images get invalidated. Then NGen needs to run to re-generate the invalid native images. This is done automatically via the .NET Runtime Optimization service which runs during idle time.
When a .NET compiler compiles C# or VB.NET code it half compiles them and creates CIL code. When you run this half-compiled .NET EXE file the JIT runs in the background and compiles the half CIL code in to full machine language. This mode is termed as normal JIT.
You can also go the other way around saying you do not want runtime compilation by running a full compiled EXE file. This compilation is done by using negen.exe. In this scenario the JIT does not participate at runtime. This is termed as pre-JIT mode.
If you want to see how they affect performance you can see this YouTube video which demonstrates normal-JIT and pre-JIT mode of compilation:
Explain JIT, Ngen.exe, Pre-jit, Normal-Jit and Econo-Jit.? (.NET interview questions)
Per MSDN:
The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly.
I have used NGEN in the past during installation so that the software would start up faster.
NGen (Native Image Generator) basically compiles .NET byte code (CIL) into native code for the computer it's running on. The benefit is that given that you're not compiling the code to native every time, you run it or need it, but you do it just once, the application starts and run faster. If you want more information there are plenty of resources out there about the benefits of JIT vs. Ahead of Time Compilation (which is what NGen does).
After upgrading to R# v6 I am unpleasantly surprised to see that the memory usage for the same application is using almost three (3) times what it did with v5.x, and is painfully slow. Not sure I would upgrade again if I had known this before hand.
Is this a known issue? Has anyone noticing the same jump been able to successfully tweak this?
Cheers,
Berryl
We're receiving mixed reports on memory and performance consumption in v6. In some cases, users call the new version a massive improvement over previous versions, other times they report increased memory consumption and lags in certain scenarios. This is pretty much the same story with every new version.
There are several known issues related to processing classic ASP files and in general processing source file on solution load. Both have been addressed lately and will be fixed in ReSharper 6.1 that is coming out later this Fall.
I suggest that you do the following:
Try to clean ReSharper caches by deleting YourSolutionName.suo and *_ReSharper.YourSolutionName* folder - this helps sometimes.
Downgrade to ReSharper 5.1.3 for the time being. This version is available via ReSharper archive.
As soon as ReSharper 6.1 comes out, install it to see if it's any better.
If it's no better, profile ReSharper and send the profile to us for investigation.
An alternative would be to profile 6.0 right away as there's a chance that your issue is something we've not yet investigated during 6.1 development.
When using 3rd party libraries/components in production projects, are you rigorous about using only released versions of said libraries?
When do you consider using a pre-release or beta version of a library (in dev? in production, under certain circumstances)?
If you come across a bug or shortcoming of the library and you're already committed to using it, do you apply a patch to the library or create a workaround in your code?
I am a big fan of not coding something when someone else has a version that I could not code in a reasonable amount of time or would require me to become an expert on something that wouldn't matter in the long run.
There are several open source components and libraries I have used in our production environment such as Quartz.NET, Log4Net, nLog, SharpFTPLibrary (heavily modified) and more. Quartz.NET was in beta when I first released an application using it into production. It was a very stable beta and I had the source code so I could debug an issue and there were a few. When I encountered a bug or an error I would fix it and post the issue to the bug tracker or author. I feel very comfortable using a beta product if the source is available for me to debug any issues or there is a strong following of developers hammering out any issues.
I've used beta libraries in commercial projects before but mostly during development and when the vendor is likely to release a final version before I finish the product.
For example, I developed a small desktop application using Visual Studio 2005 Beta 2 because I knew that the RTM version would be available before the final release of my app. Also I used a beta version of FirebirdSQL ADO.NET Driver during development of another project.
For bugs I try to post complete bug reports whenever there's a way to reproduce it but most of the time you have to find a workaround to release the application ASAP.
Yes. Unless there's a feature we really need in a beta version.
There's no point using a beta version in dev if you aren't certain you'll use it in production. That just seems like a wasted exercise
I'll use the patch. Why write code for something you've paid for?
There's no point using a beta version in dev if you aren't certain you'll use it in production. That just seems like a wasted exercise
Good point, I was also considering the scenario of evaluation of the pre-release version in dev, but I supposed that taints the dev -> test/qa -> prod path.
I'll use the patch. Why write code for something you've paid for?
What if it's not a commercial library, but an open source one? What if the patch to be applied is not from the releasing entity (e.g. your own patch)?
I use:
Infragistics (.NET WinForms controls)
LeadTools (video capture)
Xtreme ToolkitPro (MFC controls)
National Instruments Measurement Studio (computational libraries, plotting, and DAQ)
I've found significant bugs in every one of these, so I try to limit their use as much as possible. Infragisitcs is pretty good for what it is, and National Instruments is by far the best, although quite limited. I would avoid LeadTools at all cost.