Go into your iis machine level settings and add
<deployment retail="true" />
As specified in http://msdn.microsoft.com/en-us/library/ms228298.aspx
Create a new web project, add a label and then the following code.
protected void Page_Load(object sender, EventArgs e)
{
Label1.Text = HttpContext.Current.IsDebuggingEnabled.ToString();
}
//Result: true
What am I missing?
Update: I updated the value on the 64 and 32 bit versions of the machine config. The server is running IIS7.5. Reboot didn't help.
Update 2:
Stepping through V4 of the framework using Reflector I get the following code.
public bool IsDebuggingEnabled
{
get
{
try
{
return CompilationUtil.IsDebuggingEnabled(this);
}
catch
{
return false;
}
}
}
internal static bool IsDebuggingEnabled(HttpContext context)
{
return MTConfigUtil.GetCompilationConfig(context).Debug;
}
//Here is where I lose whats going on... Either way, if what Yaur said is correct then
//I believe that value is not only useless but dangerously misleading.
internal static CompilationSection GetCompilationConfig(HttpContext context)
{
if (!UseMTConfig)
{
return RuntimeConfig.GetConfig(context).Compilation;
}
return GetConfig<CompilationSection>(context);
}
Either way. What I can confirm is that the functionality does not seem to work.
PS: #Yaur - Yes I have tried changing the value and I am well aware of the alternatives to using this method but the point is that this method is supposed to simplify deployment.
According to : http://weblogs.asp.net/scottgu/archive/2006/04/11/442448.aspx, it should force :
<system.web>
<compilation debug="false">
</system.web>
Have you rebooted your server ?
Which machine.config did you edit ?
Looking at HttpContext in reflector all this method does is to load the value found in the compilation section. So set that as mathieu suggested and you you should be golden.
Also (if you care) it will throw an exception if running under mono.
from the 2.0 version of System.Web:
it calls
CompilationUtil.IsDebuggingEnabled(this);
which calls
RuntimeConfig.GetConfig(context).Compilation.Debug;
Compilation.Get returns
(CompilationSection) this.GetSection("system.web/compilation", typeof(CompilationSection), ResultsIndex.Compilation);
the 4.0 version is a bit different... based on what I can tell it looks the "extra stuff" is multitargeting support. So if you are targeting .net 4 and setting <compilation debug="false"> didn't work try following the example here and use
<system.web>
<compilation debug="false" targetFramework="4.0">
</compilation>
instead
Related
I'm currently using CloudConfigurationManager.GetSetting("setting") to get settings for my application, but it's writing logs of everything it's checking to the console (in both Debug and Release):
Getting "setting" from ServiceRuntime: FAIL.
Getting "setting" from ConfigurationManager: PASS (Data Source=...
Getting "setting" from ServiceRuntime: FAIL.
Getting "setting" from ConfigurationManager: PASS (Data Source=...
Is there any way to prevent it from doing this, or an alternative version that's less verbose?
Mostly I just like my unit test output to be nice and clean, but I'm also a little concerned that it's printing out things like connection strings (and hence passwords) in plain text on the production server.
CloudConfigurationManager.GetSetting now has a method overload with a parameter called outputResultsToTrace.
If you pass false to this method, then it'll disable the Trace.WriteLine used elsewhere to "spam" the Trace log.
So
var mySetting = CloudConfigurationManager.GetSetting("MySetting");
becomes
var mySetting = CloudConfigurationManager.GetSetting("MySetting", false);
I found this by looking directly at the source code on GitHub: https://github.com/Azure/azure-sdk-for-net/blob/52fc67253a176bea01c37c164f71c7eba8eaedba/src/Common/Configuration/CloudConfigurationManager.cs#L35
It's probably worth mentioning that this overload is not documented: https://msdn.microsoft.com/en-us/library/azure/mt634648.aspx
So I'm not sure if it's an official and supported part of the API, or if it's something that might change or go away in the future.
This change was made at the end of 2015: https://github.com/Azure/azure-sdk-for-net/commit/e14398136d7d3b6d5e4675f1e8ccbdd37a8c6b01
Not really. If you look at the code of the underlying GetValue method you'll see this:
private static string GetValue(string providerName, string settingName, Func<string, string> getValue)
{
string str1 = getValue(settingName);
string str2;
if (str1 != null)
str2 = string.Format((IFormatProvider) CultureInfo.InvariantCulture, "PASS ({0})", new object[1]
{
(object) str1
});
else
str2 = "FAIL";
Trace.WriteLine(string.Format((IFormatProvider) CultureInfo.InvariantCulture, "Getting \"{0}\" from {1}: {2}.", (object) settingName, (object) providerName, (object) str2));
return str1;
}
The Trace.WriteLine is always called without taking into account Debug or Release. Now you can simply remove the Default listener which should suppress all messages:
<system.diagnostics>
<trace>
<listeners>
<remove name="Default" />
</listeners>
</trace>
</system.diagnostics>
Now if you look at the CloudConfigurationManager it doesn't do that much. If this is a problem for you you can cook up something yourself, starting with this:
if (RoleEnvironment.IsAvailable)
return RoleEnvironment.GetConfigurationSettingValue(setting);
else
return ConfigurationManager.AppSettings[setting];
Note: The CloudConfigurationManager does a lot more than this, like loading the assembly without assembly reference.
Alternative option, if you're calling CloudConfigurationManager.GetSetting() in one part (ie, a wrapper/helper class):
var oldListeners = Trace.Listeners.Cast<TraceListener>().ToArray();
Trace.Listeners.Clear();
var stringValue = CloudConfigurationManager.GetSetting(key);
Trace.Listeners.AddRange(oldListeners);
First, we remove all listeners on Trace. Then we grab the setting, and re-add the listeners. Of course, this potentially could cause problems with threaded applications
I just installed the nuget package Microsoft.WindowsAzure.ConfigurationManager version 3.1.0, and I can confirm that the issue has been fixed in this version. Taking a look at the github issue referenced in the question's comments, we can see, in the changelog, the fetched value is no longer written to the trace output. In particular, the trace message has been changed from:
message = string.Format(CultureInfo.InvariantCulture, "PASS ({0})", value);
to:
message = "PASS";
This still makes the configuration manager quite verbose though.
We just ran into this ourselves...so very frustrating.
We can't remove the default listener because we are logging our own stuff on it.
There is an easy workaround though. Just use the good old fashioned ConfigurationManager.AppSettings["Microsoft.ServiceBus.ConnectionString"] and you will get the info you need without the annoying logging.
Hope that helps,
David
I had quite similar problems. I updated from Azure SDK 2.0 to 2.2 - during this process I used the NuGet Manager to update the Microsoft.WindowsAzure.Storage to the latest. The PackageManager automatically took Microsoft.WindowsAzure.Configuration to 1.8.0.0. I was not able to get this running (it was for .Net 2.0!?). After I manually set all References to
Microsoft.WindowsAzure.Storage 2.1.0.0
Microsoft.WindowsAzure.Configuration 2.0.0.0
everything worked.
I think this is because of the way CloudConfigurationManager.GetSetting loads the assembly and calls the funktions (via reflection).
Fixed in version 3.0.0. Please update Microsoft Azure Configuration Manager nuget package.
There are two separate issues here:
Setting values are logged in plain text (a security concern)
Messages are logged every time a setting is retrieved (a verbosity concern)
As others have noted, #1 has been fixed in a more recent version of the plugin.
Based on my experience (and some of the other responses here), #2 is still a huge annoyance.
Looking at WADLogsTable in Visual Studio's Queue Editor, note that the message level is 5 (i.e. verbose, according to this list of ETW levels).
Going off of the diagnostic config file schema, my approach to solving issue #2 was to limit the minimum severity level (e.g. warning, informational, verbose) of generic tracing to "information" (or more severe) and just ensure my own logging did not use the "verbose" level.
Here is the change I made in diagnostics.wadcfgx:
Original:
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Verbose" />
Fixed:
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Information" />
After switching to .net 4.0, some javascript code from a third party gridview crashes.
It has got something to do with HtmlEncode and UrlEncode now encode single quotation marks
So before some code on the page was inserted like this:
DataItem.GetMember('Id').Value
and now its like this: DataItem.GetMember('Id').Value
The gridview does an eval on that line, and crashes with a syntax error now. I can't change the javascript code in that gridview.
Is there anyway to solve this, without going backwards like this?
<pages controlRenderingCompatibilityVersion="3.5" />
EDIT: the pages controlRenderingCompatiblityVersion doesn't fix this also. Single quotes are still encoded.
From what I've read, it's a security feature and Microsoft is mum about changing it. The only work-around I've seen is you will need to create a custom encoder class. You can turn-off attribute encoding using this:
public class HtmlAttributeEncodingQuote : System.Web.Util.HttpEncoder
{
protected override void HtmlAttributeEncode(string value, System.IO.TextWriter output)
{
output.Write(value);
}
}
Then add this to web.config under system.web:
<httpRuntime encoderType="HtmlAttributeEncodingQuote"/>
I'm working with WPF. When I'm trying to declare SQLiteConnection in the code, the problem arises-
The invocation of the constructor on type 'TestWPF.MainWindow' that matches the specified binding constraints threw an exception.
InnerException: Make sure that the file is a valid .NET Framework assembly.
can anyone tell me, how to fix it?
If you click on View Detail... from the exception window you can look at the InnerException. Expand that node and you will see exactly what went wrong.
In my specific case, I was getting this because I had a few of my referencing assemblies mismatched between x64 and x86. Apparently I was binding to something that needed to be loaded by the runtime.
I mention this here as a reminder to check your build configurations if you've looked everywhere else!
I fixed the problem by adding the below content in app.config,
<configuration> <startup useLegacyV2RuntimeActivationPolicy="true" /> </configuration>
I found this via a community addition by user FCAA below the article "
Troubleshooting Exceptions: System.IO.FileLoadException" on MSDN.
I got the same error and, after wasting about 2 hours with it, found that it is my SQL Server service that's not running. Not sure if this can ever help someone, but it did solve my problem to just start the service.
The mentioned exeption is quite generic and you can receive it, for instance, when code fails in the constructor. I had a case of an IO exception that showed up with a similar text. Stepping into the code may provide hints to fix this that may not be obvious otherwise.
I got it in when I specified the FrameworkPropertyMetadata of a DependencyProperty with a default value
the defaultValue was
new AdressRecord { Name = "<new>", Adress = "?" }
i replaced with
default(AddressRecord)
and vs2015 ate it
public static readonly DependencyProperty AdressRecordsProperty =
DependencyProperty.Register("AdressRecords",
typeof(ObservableCollection<AdressRecord>),
typeof(PageViewModel),
new FrameworkPropertyMetadata(
default(AdressRecord),//This noes not work: new AdressRecord { Name = "<new>", Adress = "?" },
OnAdressRecordsChanged));
I ran into this issue and it was caused because my startup application was built as any CPU but I was referencing a project that was built as x64. Setting the startup to build x64 resolved the issue.
In VS2015 I was able to see the specific code causing this problem once I turned on 'Enable Just My Code' in the Debugging Options under Tools -> Options.
I had this error in another part of code which has to do with my application resources.
This was fixed after explicitly setting the ResourcePath folder in my App.config file
I had the same problem. i could make it work by renaming the name of App1.config to App.config. I tried all other methods but the solution for me was to change the default name (for me it was App1.config) of the config file to App.config. I shared this because someone may get help by this small modification.
My problem was about the interface. I fixed it by deleting the Betternet folder that is located at C:\ProgramData.
Hidden Items/Folders must be shown in order to be able to view the folder.
With Visual Studio it will sometimes not show anything in the exception details or even have them, running the diagnostic tool however can easily pinpoint what is wrong.
Try Adding "Integreted Security = True" in Connection String.
It worked for me.
In my case it happened in a code-first WPF project. The cause was model changes after restoring a backup, and the error was not being handled appropriately. "The model backing the 'MyDataContext' context has changed since the database was created." Update-Database sorted it out.
I had to change the target .Net framework from 4.5.2 to 4.
my issue was regular System.IndexOutOfRangeException error in my own code,
but received this weird error because my code was called inside:
public MainWindow()
{
InitializeComponent();
// my code with error
}
same issue, if call it inside:
private void Window_Initialized(object sender, EventArgs e)
{
// my code with error
}
Fixed, if I call my code inside:
private void Window_Loaded(object sender, RoutedEventArgs e)
{
// my code with error
}
Then i get correct error message for IndexOutOfRangeException in my code.
I recently tried to upgrade a .net 2.0 project which had its DAL generated by SubSonic 2.2 to .NET 4.0 under Visual Studio 2010.
The projects converted without error but now I am getting a rather vile error message when I try to launch it.
System.Security.VerificationException: Operation could destabilize the runtime.
at SubSonic.DataProvider.ApplyConfig(NameValueCollection config, Boolean& parameterValue, String configName) in C:\Documents and Settings\Desktop\4.0 Production\rel_1.0\server\Server.DAL\Server.DAL.SubSonic\DataProviders\DataProvider.cs:line 955
at SubSonic.DataProvider.Initialize(String name, NameValueCollection config) in C:\Documents and Settings\Desktop\4.0 Production\rel_1.0\server\Server.DAL\Server.DAL.SubSonic\DataProviders\DataProvider.cs:line 916
at System.Web.Configuration.ProvidersHelper.InstantiateProvider(ProviderSettings providerSettings, Type providerType)
The code where it is throwing the exception:
ApplyConfig(config, ref extractClassNameFromSPName, ConfigurationPropertyName.EXTRACT_CLASS_NAME_FROM_SP_NAME);
private static void ApplyConfig(System.Collections.Specialized.NameValueCollection config, ref bool parameterValue, string configName)
{
if(config[configName] != null)
{
parameterValue = Convert.ToBoolean(config[configName]);
}
}
It performs similar calls to here, the only difference being it is strictly a string and not a boolean it is manipulating.
private static void ApplyConfig(System.Collections.Specialized.NameValueCollection config, ref string parameterValue, string configName)
{
if(config[configName] != null)
{
parameterValue = config[configName];
}
}
config is defined as a System.Collections.Specialized.NameValueCollection with 3 keys
generateNullableProperties, connectionStringName, generatedNamespace
extractClassNameFromSPName == false
EDIT1: The code that kicks off the error is in the Application_Start() method of the Global.asax
System.Data.SqlClient.SqlDependency.Start(SystemSetting.Schema.Provider.DefaultConnectionString);
EDIT2: The error bubbles out to thowing a targetinvocation error referening my web.config
<SubSonicService defaultProvider="appPlan">
<providers>
<clear/>
<add name="appPlan" type="SubSonic.SqlDataProvider, appPlan.Server.DAL.SubSonic" generateNullableProperties="false" connectionStringName="appPlan" generatedNamespace="appPlan.Server.DAL"/>
</providers>
</SubSonicService>
has anybody else ever run across such an issue? I could upgrade to SubSonic3.x but it would be a much greater undertaking I believe.
thanks.
I have seen this exception before when generating assemblies directly from hand-crafted IL. The .NET runtime verifies the raw instructions in an assembly for correctness, especially when loading the assembly into restricted contexts. For example, there is a check to ensure that the required number of arguments are loaded onto the call-stack before executing a method.
An assembly can still be loaded even if verification fails; but it can only be run in full trust. In partial trust scenarios you get this "operation could destabilize the runtime" error. The reason being that the runtime cannot guarantee safe operation of assemblies in partial trust if they do not "behave correctly".
You can manually check an assembly using the PEVERIFY tool (available via a Visual Studio Command Prompt). Try verifying all of the referenced assemblies to see what is reported. I suspect there was a change in the verification rules between .NET 2.0 and .NET 4.0 that is now causing verification to fail for one of the SubSonic 2.2 assemblies.
Your cheat you mention in response to Fun Mun Pieng also suggests verification is the issue.
Does this fix the problem?
private static void ApplyConfig(System.Collections.Specialized.NameValueCollection config, ref bool parameterValue, string configName)
{
if(config[configName] != null)
{
string val = config[configName];
parameterValue = Convert.ToBoolean(val);
}
}
If not, then try
string val = config[configName];
if (val.ToLower() == "false")
parameterValue = false;
else
parameterValue = true;
There may be 2 reasons why the original code fails. First, earlier version of .NET (probably 1.1) had some type issue. I don't know what exactly, but I suspect it might have failed to identify the type of the value passed straight from the NameValueCollection into ToBoolean. The second possibility is that the value is not "true" or "false", but something else. Again, these 2 may or may not be the reason. I can't know for sure because I don't have SubSonic 2.2.
Interfaces (In the assembly named "Interfaces". In project :- Interfaces)
namespace Interfaces
{
public interface IDoSomeWork1
{
string DoSomeWork1();
}
}
namespace Interfaces
{
public interface IDoSomeWork2
{
string DoSomeWork2();
}
}
Dependencies (In the assembly named "Entities". In project :- Entities)
namespace Entities
{
public class ClassB : IDoSomeWork1
{
public string DoSomeWork1()
{
return this.ToString();
}
}
}
namespace Entities
{
public class ClassC : IDoSomeWork2
{
public string DoSomeWork2()
{
return this.ToString();
}
}
}
Class (In project :- UsingUnity)
public class ClassA
{
[Dependency]
public IDoSomeWork1 DoSomeWork1 { get; set; }
[Dependency]
public IDoSomeWork2 DoSomeWork2 { get; set; }
public void SomeMethodInClassA()
{
Console.WriteLine(DoSomeWork1.DoSomeWork1());
Console.WriteLine(DoSomeWork2.DoSomeWork2());
}
}
App.Config (In a console application project :- ConsoleUsingUnity)
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="unity"
type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,
Microsoft.Practices.Unity.Configuration" />
</configSections>
<unity>
<containers>
<container>
<types>
<type type="Interfaces.IDoSomeWork1, Interfaces"
mapTo="Entities.ClassB, Entities" />
<type type="Interfaces.IDoSomeWork2, Interfaces"
mapTo="Entities.ClassC, Entities" />
</types>
</container>
</containers>
</unity>
</configuration>
The client (In a console application project :- ConsoleUsingUnity)
public class Class1
{
static void Main(string[] args)
{
IUnityContainer container = new UnityContainer();
// Load from config file
UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
section.Configure(container);
ClassA classA = container.Resolve<ClassA>();
classA.SomeMethodInClassA();
}
}
And when I run the client, I get the following error at section.Configure(container);:-
The given assembly name or codebase
was invalid. (Exception from HRESULT:
0x80131047)
I am not sure If there is anything wrong with the config or the type. Could anyone please point out the mistake here?
In case anyone else ever has the same problem - I was also getting this error but had a slightly different problem. I was trying to load an assembly that clearly existed like the following:
Assembly.Load("C:\\Program Files\\MyProgram\\MyAssembly.dll");
After lots of trial and error I figured out that you aren't supposed to pass the path and you certainly aren't supposed to include .dll extension. The following fixed my issue:
Assembly.Load("MyAssembly");
Hopefully that helps someone else sooner or later!
Before I answer my question, I must state that the code posted above didn't give me any problem (build error etc.). It just gave me the error I stated in my question. The problem with Unity at this point of time is that It does not provide which assembly or a which types in the assembly could not be loaded. This is a requested feature.
In my case It was a missing assembly problem. I didn't reference Entities assembly in to the client application project. It seems that that "Entities" assembly could be resolved only at the run-time (since it didn't give me any compile time error). However, the run-time error was also not useful at all.
I had a look a Fusion Log viewer (It should be in the .NET SDK folder). What a gem of an utility It is. It can log all kind of assembly bindings (all or only failures) and It give a very neat description of which assembly could not load. Very helpful!
So, next time, you get this "The given assembly name or codebase was invalid" error, try Fusion Log Viewer. It wont help you in finding which types couldn't be loaded. However,at least you will be sure all your assemblies are getting loaded correctly.
If you connect up the domain AssemblyResolve event you can get the assembly that has failed to bind.
AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);
There is a better way now!
Unity has a new version (currently 2.1.505.2) which clearly reports the details and lets you get to the bottom of it immediately.
You can find binaries and source here: http://unity.codeplex.com/releases
I found that the least time consuming method of finding which Type exactly failed to bind is the following:
Go to Sources section of Unity page at codeplex http://unity.codeplex.com/SourceControl/list/changesets
Select a version and download the sources
Build DEBUG version of Unity and Unity.Configuration (if your project uses more of unity assemblies, build them as well)
Remove references to unity from your project and add references to assemblies from step 3
In Visual Studio go to Debug > Exceptions and make sure Common Language Runtime Exceptions has a checkbox in the Thrown column.
Now go crash that thing. Execution will stop in Unitys' TypeResolverImpl.SearchAssemblies method and typeNameOrAlias parameter will hold the answer!
works like this
Dim dllData = System.IO.File.ReadAllBytes(dllFullPath)
Dim asb As System.Reflection.Assembly
asb = System.Reflection.Assembly.Load(dllData)
Dim cls As Object = asb.CreateInstance("namespace.class")
Please make sure, that you have added assembly references of the missing assembly in the project where your web.config file exists.
I was missing this. I already have added those assembly references in the project which was using Unity to resolve the class, but missed to add it in the parent project where configuration file was located. This has resolved my problem.