Visual studio injects
<WcfConfigValidationEnabled>True</WcfConfigValidationEnabled>
into my csproj.
What does this property do, and is there any reason why I would want to disable it?
I believe VS is checking the WCF configuration syntax as part of the build process. It will then be able to alert you to any configuration errors before you run the code.
You can disable it if you want, but then if configuration errors occur during development, they will be only be seen at runtime.
Its more a design time convenience, than a runtime convenience.
Related
Compilation Error
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: The compiler failed with error code -2146232576.
Clean and Rebuild your solution (under Build menu). If it gives you any compilation errors, correct them and build it again. That worked for me.
Edit 3/12/18
It seems like you have read, or possibly write, locks on one or more files. Close the studio and verify that the source code repository don't have orphaned read/write locks. Also verify that any directories used for compilations don't have read locks. There used to be a weird Temporary ASP.NET-folder that was prone to locking files in the good old days.
Previous response
These are a few things that come to mind in my experience. I am assuming the deployment machine is a Windows Server of sorts.
Check the expected .NET version by checking project properties in Visual Studio (or the Project-files if another editor is used).
Compare with the installed version of .NET of the deployment machine. Framework on the deployment machine should equal to or greater than .
Verify the chosen app pool is running the expected version (or change it) and recycle it.
Make sure all the necessary assembly files (.DLLs) have been included on the deployment machine. A quick look into the BIN or DEBUG folder usually tells the story, but will generally also contains a whole lot more stuff. Sometimes too many assembly files removed during optimisation of the build.
A little bit of information about deployment OS and .NET versions would help.
I have my dlls (.NET4) build with msbuild and obfuscated with SmartAssembly 5.5.
After that i set them with reference for simple console application in the MonoDevelop (latest) on Mac (10.8).
Built ok, but when i ran that simple app, i have a message:
Unknown heap type: SmartAssembly
I asked SA support but no luck yet (the saproj have item blabla(supports Mono) checked.
I dont see how to attach a screenshot, but, when i run my application i see in the console that message twice. It appears before program stops on the breakpoint on the first line of code.
So maybe someone knows what to change in SmartAssembly or in MonoDevelop to remove this problem ? Thanks
Many .NET obfuscators change the assemblies such that they are not technically correct assemblies (they fall outside the .NET assembly specs) but such that they still run on the Microsoft .NET runtime by exploiting bugs specific to Microsoft's implementation. I suspect they do this to make it harder for assembly reader tools/libraries to load the assemblies. Unfortunately, this also prevents Mono runtime from loading the assemblies. In general Mono has a policy of not "fixing" support for this kind of invalid obfuscated code, so you'll need to ask SmartAssembly support for help.
If you're certain you're compiling with SmartAssembly's "Strictly valid" option and it's not working, perhaps you could perhaps try their "Basic" option.
Any way to replace visual studio's usage of msbuild and still get error reporting in the IDE? I think I might want to compile in VS with NAnt or Rake or PowerShell, or something that is just as smart but uses a scripting language instead of XML. My build is fairly straight forward -- find all the .cs and compile them and put the dll in a Debug/ or Release/ etc.
I'd like to add a number of other steps that just seem easier from the command line:
Like hit the server to prime certain caches.
Compile with Closure
Minify CSS
Generate some metrics after build (in a certain config)
Run NUnit (or custom) testing framework and send an email
etc....
However, I'd still like to get the "error on line" feed back inside of the IDE. Is this a possibility?
You could write some extension for Visual Studio (Macro, AddIn, Package, etc.) that can augment Visual Studio to let other build tools run. The simplest form is probably just using "Tools\External Tools.." and add your Build Tool there. As long as you format your "build messages" as described here, the should show up the output window as if they were generated by MSBuild.
However, I don't think it is possible (nor desirable, BTW) to completely replace MSBuild in Visual Studio.
Visual Studio not just executes MSBuild.exe and parses it's output. The integration is very tight and a lot of GUI aspects rely directly on the content of the MSBuild file.
For example, when you change some project properties in the Visual Studio UI, the changes are (eventually) written to the MSBuild file of the project.
Also, there are some performance improvements, for example Visual Studio "replaces", so to say, the call of csc.exe (the C# compiler) from an MSBuild file by using an in-process compiler, which safes some compile time, because less external processes need to be launched (also described in the above mentioned document)
While all this, from a architectural point of view, is quit likely wrapped and encapsulated by some "interfaces" inside Visual Studio, I haven't yet found a way to have those "interfaces" implement something else that, for example, uses NAnt behind.
Anyway, I think even if technically possible, it would not be technically feasible.
For rake, check out Rake Runner extension. You can run the rake tasks from the solution explorer and check the errors and other output in the Output pane. I have little experience developing vs packages so if anyone want to help, the project is open sourced here.
I have a build-server running CC.Net. So far I never had any problems compiling projects on the build server (which has no VS installed, just use the .Net Framework).
But now I have a new projects and I get this message:
C:\Program Files\MSBuild\Microsoft\Windows Workflow Foundation\v3.5\Workflow.Targets(127,5): error : Compilation failed. Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
Has anyone any hint's on what's causing this problem?
What might be of some interest is the fact, that this is a SharePoint project wich includes a SharePoint workflow. But this shouldn't stop the project from being able to be compiled.
The problem with LoaderExceptions described here sounds like what you are seeing. Maybe targeting 3.0 instead of 3.5 does fix your issue too.
We've just newly decided to use NServiceBus on our project and we're experiencing some problems. Rather than "ask for a fish" every time we hit an issue, we'd prefer to "teach ourselves to fish". This means setting things up so we can step into the NServiceBus source code and understand NServiceBus more deeply.
We need some help figuring out how to pull this off. It is unclear how to get Visual Studio to successfully build NServiceBus upon each compile, since NServiceBus comes with its own Nant build process that uses ILMerge to create consolidated assemblies and so forth.
We have already tried building NServiceBus with the Nant script and then referencing those dlls and pdb's. However, that does not let us step everywhere, and it also does not let VS.NET and Resharper navigate via "Find Usages" and other features.
So what we would really like to create is a VS.NET Solution that builds our in-house software and NServiceBus, and allows us to seamlessly Step and Navigate between them.
Is this possible? What would we need to do to pull this off?
Not quite the exact answer you were looking for, but you can check out the post i made on debugging into NServiceBus which involves the following steps:
Downloading the source code.
Building the source code using the
"build.bat"
Then referencing the
dlls and pdb files in your
solutions, so that you can step into
the NServiceBus source code.
I've successfully change the logging behaviour to always to a Message.ToString() in our code so that the Log4Net logs were a bit clearer.
Check it out here:
http://www.craftyfella.com/2010/12/debugging-into-nservicebus-so-you-can.html
Hope it helps.
Dave