I tried using the SlowCheetah extension, but I can't seem to get it to work. I think i may have missed a step somewhere.
I downloaded the extension and installed it.
The i created my web.config file and did the "add transform"
To test it, I was already using ELmah in my project, so I tried giving it different email address to send the error log for every config, and none in the web.config.
web.config
<elmah>
<security allowRemoteAccess="0"/>
<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="C:\myLogPath"/>
<errorFilter>
<test>
<or>
<equal binding="HttpStatusCode" value="404" type="Int32"/>
<is-type binding="BaseException" type="System.FieldAccessException" />
</or>
</test>
</errorFilter>
</elmah>
web.debug.config
<elmah>
<errorMail from="error-debug#domain.tld" to="me#domain.tld" priority="High" xdt:Transform="Insert"/>
</elmah>
So, when i look at "preview transform", it seems like the result is what i want. Then I start my application (either with F5 or ctrl+F5) and purposely throw an exception on my website to trigger Elmah error reporting, but I never get any email. If I add the errorMail line in my web.config, I do get an email, so the problem is not coming from Elmah.
As I said, i feel like I may have missed a simple step in setting up the extension.
The problem you are running into isn't really with SlowCheetah, but how you are launching your web application from Visual Studio.
SlowCheetah will indeed add the necessary MSBuild Targets to your project in order to do transforms upon build, but only for things included in your project output (i.e. the \bin folder).
When you build a web application your web.config stays put, and only the assemblies are copied into your \bin folder. Visual studio fires up the WebDev server and points it to the root directory of your web application. Since your web.config hasn't been modified, it will always contain the original contents.
To my knowledge, slow-Cheetah supports config transforms for the app.config files but not web.configs on debug at present. It should put a transformed web.config file in the bin folder of your project but your project still reads from the config file in the root folder. Please have a look at a workaround at http://sedodream.com/CommentView,guid,68b7e248-b9f5-4d07-bdfe-eb037bcf2cbb.aspx. This works for me instead of using Slow-Cheetah.
You can also request for web config transform support for Slow-Cheetah on debug at
https://github.com/sayedihashimi/slow-cheetah/issues/39 They are considering adding web support on F5 to it.
Related
I have 2 resource file.. one is default for english and another one is for chinese.
The web app is working fine with VS but when I published it on IIS its not showing chinese language.
I tried other solutions available on stackoverflow but nothing seems to work yet.
I can find resources.dll inside zh(bin) folder on IIS.
Is the error because of there was only one designer file generated that is Resource.designer.cs or something else.
I have made the required changes in Resource File properties like making the class public and build action.
IN web.config I changed
<globalization enableClientBasedCulture="true" uiCulture="en-US" culture="en-US" />
from false to true.
Please ask if Any other information needed to solve this issue.
Please give me some advice on this.
When I published it in the beginning the App_GlobalResources didnt get copied on server. I was able to see a resource dll for chiese in bin folder on server but it was of no use I think. doing republishing of website on my server after some changes, got me the desired result. here are the things that I changed -
I went to properties of resource file and changed -
Build to - Content
Copy to output directory - copy always
custom Tool- PublicGlobalResourceProxyGenerator(made both resource
file public)
and then in web.config I changed
<globalization enableClientBasedCulture="false" uiCulture="en-US" culture="en-US" />
to
<globalization enableClientBasedCulture="true" uiCulture="en-US" culture="en-US" />
Then I published it and got the chinese option working.
I am working on an ASP.NET C# project, where I would like to make use of web.config transforms.
I therefor installed the extension "Configuration Transform" and added a Web.Debug.config and Web.Release.config.
Within the Web.config I have not declared anything specific to my application. The debug config contains my testing/developing settings while the release config contains tokens #{someVar}# that later will get replaced by TFS.
When I publish my application the Web.config gets correctly created according to the configuration (debug/release). Also Preview config transform gives the correct result (besides the line breaks).
However when starting the application from within Visual Studio 2017 with debug configuration it complains about missing tags.
Why is that and how can I fix this?
Web.config
<!-- Does not contain the request tag -->
Web.Debug.Config
<request xdt:Transform="Insert">
<mysetting>MyDevelopmentSetting</mysetting>
</request>
Web.Release.config
<request xdt:Transform="Insert">
<mysetting>#{MyTokenThatWillGetReplacedByTFS}#</mysetting>
</request>
Web config transforms do not run in Visual Studio (when you press F5/run the app in VS). They only run on builds when publishing.
Since your web.config doesn't have the setting and the application is expecting it, it's properly complaining about the missing tag.
You will need to add this tag to your web.config.
We're building an ASP.NET MVC 4 app in Visual Studio 2015. The app uses Elmah.MVC for exception handling. We're three developers; for two of us it's working fine on localhost, but one developer is getting this error (captured by Elmah):
The controller for path '/favicon.ico' was not found or does not implement IController.
This post provides a solution, and I've modified the routes to include it and the developer in question has synced his code:
routes.IgnoreRoute("{*favicon}", new { favicon = #"(.*/)?favicon.ico(/.*)?" });
Now nothing shows up in Elmah but the user continues to see a generic error:
500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.
What could be going on? Thanks.
Update 1: Ripped out the Elmah stuff from Web.config and just had the developer load the app. It gets into an infinite loop trying to authenticate the user, similar to this.
We're using OWIN-MixedAuth, and the issue is more than likely on the IIS Express settings. I'll have the developer try it tomorrow and confirm:
Highlight the project in Visual Studio
Open the 'Properties' panel on the right (or press F4)
Set 'Windows Authentication' to 'Enabled'
Set 'Anonymous Authentication' to 'Enabled'
As the name suggests, it's mixed auth, so both types of authentication have to be enabled.
Update 2: The OWIN-Mixed Auth issue has been fixed. Now, it has something to do with these three HTTP modules in Web.config used by Elmah:
<httpModules>
<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah" />
<add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah" />
<add name="ErrorFilter" type="Elmah.ErrorFilterModule, Elmah" />
</httpModules>
When we comment them out, the one developer is able to get onto the site. What do these modules do? Why would they cause a problem?
Finally resolved the issue. We had to make two changes:
We're using OWIN-MixedAuth, and part of the issue was on the IIS Express settings (under "Development Server" section):
Highlight the project in Visual Studio
Open the 'Properties' panel on the right (or press F4)
Set 'Windows Authentication' to 'Enabled'
Set 'Anonymous Authentication' to 'Enabled'
Another part of the issue: a corrupted applicationhost.config file used by IIS Express:
Ensure you're showing hidden files in Windows Explorer.
Go to the root of your project via Windows Explorer.
Open the hidden .vs folder.
Go to config > applicationhost.config, make a backup, and open it in Notepad (Notepad++ is better).
Compare it to a working applicationhost.config file from one of our machines. We found lots of old sites that were listed in the config file which were not being used anymore.
Once cleaned up, launched the app and it worked.
Add this to your global.asax file.
routes.IgnoreRoute("favicon.ico");
I am writing a Web API 2.0 project and a test project using Visual Studio 2013.
In the test project, I saved some information in the Settings.settings file (under TestProject->Properties in the Solution Explorer). One of the things saved there is the connection string to a database that is stored locally.
Unfortunately, the connection string will be slightly different on each person's computer when they download the repo. When people push their code to the master repo it overwrites the connection string, affecting everyone else.
What is the best way to make this configurable for each user such that everyone can have their own database path, but pushing to master repo won't affect anyone?
Edit
I don't think this is exactly a duplicate of that other question. Although, yes, my configuration settings are stored in app.config (since they happen to be application settings rather than user settings), following the solution in the other answer will lead me with the same problem. The app.config will contain configSource="otherconfig.config", and when people push that file to the master repo, it will still clobber other people's values. I need something that allows the custom configurations to be source-controlled without affecting the other users of the project.
Visual Studio handles this automatically for WEB projects through Web.config transformations
You'll need to install a separate plugin for use with App.config and non-web projects. http://visualstudiogallery.msdn.microsoft.com/579d3a78-3bdd-497c-bc21-aa6e6abbc859
The plugin basically adds the same functionality to app.config files, and works with the same syntax in the transform files.
Your best approach to this is to use Build Profiles. Have a developer-specific Web.developer.config and with that you get each user to choose their name in Configuration Manager. Then just make the new config, which is technically an XSLT make the changes needed for each team member.
Think of it as Debug vs Release configs, except in your case you'll have many Debug (one for each user). The Build profile you set doesn't get checked into TFS, so you're fine.
This is what a subconfig looks like:
<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<!--
In the example below, the "SetAttributes" transform will change the value of
"connectionString" to use "ReleaseSQLServer" only when the "Match" locator
finds an attribute "name" that has a value of "MyDB".
-->
<connectionStrings>
<add name="RavenDB" connectionString="Url=http://xxx/databases/xxx" xdt:Transform="Replace" xdt:Locator="Match(name)"/>
</connectionStrings>
<appSettings>
<add key="BaseUrl" value="http://xxx" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>
<system.net>
<defaultProxy enabled="true" />
<mailSettings>
<smtp xdt:TrandeliveryMethod="Network" transform="Replace">
<network xdt:Transform="Replace" host="xxx" defaultCredentials="true" />
</smtp>
</mailSettings>
</system.net>
</configuration>
More info on web.config transforms
http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
The way I handle this problem is by adding a folder into my app that has only assets that don't get included in the build/publish. One of the things I include in that folder is DeveloperName.App.config files for each of my developers. Then I leave the the actual App.config file out of source control. When they check out the project, they copy their personalized DeveloperName.App.config file to the project folder and rename it to App.config.
This isn't perfect, but it gives you at least most of the goals you're looking for: The developers each get their own App.config file they can maintain and keep in source control. And the changes they make to App.config don't clobber each other every check-in.
The setup is this:
.NET 4.5
Visual Studio 2012
Azure 2.0
one WebRole which hosts 2 sites:
one MVC4
one WCF project
When I published the site to the cloud, it looked like it was working in debug mode.
I published it by right-clicking the cloud project, clicking publish and selecting the config version and the "release" build version when it prompted.
To check what happened, I opened up the .cspkg file by changing the extension to .zip, and checked the .cssx file in it (also changed the extension to .zip). This allowed me to see the sitesroot/0 and sitesroot/1 folders which had my website and service. These contained source code, even the .csproj files. To compare, I checked another solution on the cloud, which just had the bin folder and the only non-compiled code were the views and .js scripts and stylesheets.
I've made sure that the compilation element in the individual projects' configs looked like this:
<compilation debug="false">
Anyway, whatever I do it looks like it builds a package in debug mode. I'm completely in a loss, and I don't know what to look at anymore, since everything looks fine.
This question shows a related problem:
VS publish to azure uses debug instead of release
But they're using TFS to automate the build and publish process, while I'm doing it manually.
Any tips or pointers would come in handy. Or at least a list of things to check and compare with other projects.
After a bit(lot) more digging, I've found the reason. It's the multiple sites on one web role that cause issues. Since the site code just gets copied into the sitesroot folder.
I've managed to solve the issue following the article here:
http://michaelcollier.wordpress.com/2013/01/14/multiple-sites-in-a-web-role/
What needs to be done is:
setup prebuild and postbuild events on each of the sites to take care of copying the built dlls into a custom build folder
Pre (clears the custom build folder):
rmdir "$(ProjectDir)..\YOUR-AZURE-PROJECT\Sites\$(ProjectName)" /S /Q
Post (copies dlls to the custom build folder):
%WinDir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe "$(ProjectPath)" /T:PipelinePreDeployCopyAllFilesToOneFolder /P:Configuration=$(ConfigurationName);PreBuildEvent="";PostBuildEvent="";PackageAsSingleFile=false;_PackageTempDir="$(ProjectDir)..\YOUR-AZURE-PROJECT\Sites\$(ProjectName)"
change the sites elements in ServiceDefinition.csdef to point to the custom build folder
<Sites>
<Site name="WebSite" physicalDirectory="..\..\Sites\WebSite\">
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint2" />
</Bindings>
</Site>
</Sites>