I’ve just enabled config transformations on a .NET 3.5 project in VS2010 RC after watching Scott Hanselman’s video on web deployment. Unfortunately every time I go to publish I now get the following error:
The "TransformXml" task failed
unexpectedly.
System.UriFormatException: Invalid
URI: The URI is empty. at
System.Uri.CreateThis(String uri,
Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString)
at
Microsoft.Web.Publishing.Tasks.TransformXml.Execute()
at
Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at
Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost
taskExecutionHost, TaskLoggingContext
taskLoggingContext, TaskHost taskHost,
ItemBucket bucket, TaskExecutionMode
howToExecuteTask, Boolean& taskResult)
If I take a brand new VS2010 web application which already has the config transformations by default I don’t have a problem so I suspect my issue is project related. Has anyone come across this before or have any ideas on a fix?
Looks like the answer was simple yet obscure; I had an app setting (a password), which contained a ">" symbol. I tried converting the app to .NET 4 then back to .NET 3.5 and everything ran fine as during the process the symbol had been escaped to ">". Never had a problem with this character until config transformations came along but at least the fix is now simple.
Edit: blogged about in a bit more detail: Visual Studio 2010 Config Transformations TransformXml task failure
FYI: my project was already targeting .NET 4.0, so I switched it to 3.5 and then back to 4.0 and it works that way as well.
Related
.NET 3.1 App was working fine before but today after I tried to run it through IIS, it is giving me this error.
given messsage error
browser shuts down after this
This is how event viewer looks
and also I noticed something, I'm not sure if it is important, in applicationhost.config there are lines about .Core2 (I'm using .Core 3.1)
I solved it by creating a new project and copying everything (except Program.cs and Startup) in it with some necessary configurations in Startup.cs like ConnectionString and Mapping
You could have also enabled the startup errors logging.
That way you would know what went wrong for the next time.
I'm going crazy with this error mainly because I have no idea what, or who is generating it. When I try to publish to azure or to IIS, in the publish started part the publish option breaks with error:
tsc(0,0): Error TS6048: Compilación:Locale must be of the form <language> or <language>-<territory>. For example 'en' or 'ja-jp'
The application has two simple localisations 'es-MX' and 'en-US' and when I publish locally everything runs normally and I get an publish output, but in this case the locale 'es-ES' is used. I honestly don't know where to start debugging or changing configurations so this can work.
What I'm thinking is to remove localization, but that could take an amount of time, also to simple remove js libraries. Any help is appreciated.
I find the similar issue on the github, it seems that it is an issue of visual studio 2017. And there is a work around, please have a try.
As a workaround, set the PreferedUILang in your project to a different language, e.g. en-us
<PropertyGroup>
<PreferredUILang>en-us</PreferredUILang>
</PropertyGroup>
I am using a COM dll in my .Net web application. This works fine on multiple different machines.
However on one particular machine I get the following error:
Unable to cast COM object of type 'CServer.CApplicationClass' to interface type 'CServer.ICApplication'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{CF0DFA28-046B-4C7D-8AA9-F4B7477D8CAE} ' failed due to the following error: Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).
I have registerd the dll using the regsvr32 command.
I have also created a COM+ application for this dll.
Running a search through the registry
I can find the key in numerous places.
I have also tried unregistering the dll and deleting all referneces on the computer to this dll. And afterwards re-adding the dll and re-registering it.
I have written a simple windows script file which tests the dll. This works fine. However the problem exists in my .net project which is running in iis.
Can anyone help me with this?..
If you need anymore info please leave a comment. Thanks.
I had a similar problem, with the "TYPE_E_CANTLOADLIBRARY" message.
Background:
I had a project which used Interop.ReferenceA.dll. This file was created using tlbimp ReferenceA.dll /out: Interop.ReferenceA.dll.
Solution:
When I took a look at ReferenceA.dll using RegDllView I noticed that ReferenceA.dll had a subclass, which was the IID shown in the error message.
I looked around in the source code of the subclass and noticed that it had a dependency to Interop.ReferenceB.dll.
Turns out that the subclass needed Interop.ReferenceB as a type-library to work. So I ran this:
regasm /tlb:Interop.ReferenceB.tlb Interop.ReferenceB.dll (the 32-bit version of regasm was used.)
And the error went away.
Make sure your AppPool is set to x86. Also make sure your assembly is targeting only x86.
I was having a similar issue. First got Access Denied, which after some looking around was resolved, only to be faced with this error message (TYPE_E_CANTLOADLIBRARY). Mind that I'm running a COM+ Component on Windows 7.
After some fruitless attempts which involved messing with the registry, my workmate and I found a way of getting it up and running:
1) Unregister your dll (regsvr32 -u dllname)
2) make sure your references to the dll are cleared up from registry (backup first)
3) Create an empty com+ application (server app) in Component Services
4) Copy the application id to the clipboard
5) go to "c:\program files (x86)\Complus applications" and create a folder with the id on your clipboard
6) copy your dll into that folder and register it
7) Go back to your Component Services and add the component to the app you created using the dll on "c:\program files (x86)\Complus applications{*app id*}"
that did it for me. Hope it helps.
I had a similar problem where the error was triggered on my PC but not on that of other developers.
It turns out that I had been testing an automatic build process on my PC that had updated the version number of the assembly, thus registering the TLB in the registry with a version number higher than the one we were normally using.
When trying to get the interface, the server was consistently using the wrong TLB information leading to the wrong assembly. Once I deleted the higher version entry in the registry, it worked fine.
Now we just have to ensure the build process is not going to cause that issue again. :)
while studying a way of properly detecting crawlers on our ASP.NET application, I came across Owen Brady's broswercaps project.
In order to use it, I did this:
Created App_Browsers folder
Created Spiders folder in the above
Downloaded [OceanSpiders.browser.xml][2] and renamed it to OceanSpiders.browser
so, the final final looking like App_Browsers/Spiders/OceanSpiders.browser
I do have NET Framework 4 installed on my dev machine, but targeting NET Framework 3.5
The problem is a parser error: 'The browser or gateway element with ID 'docomon505i' cannot be found.'
I did google/search on SO, but could not find a solution, hence my reason for posting.
Thank you for any suggestions.
It sounds like the web server is running against 4.0 run time and not the 3.5 run time, as it is reading the new Browser files which do not have docomon505i definition in them.
I have created a new VS2008 ASP.Net Web service project, with the default name WebService1. If I right click on the Service1.asmx file and select 'View in Browser' what are the processes that go on to make this happen? I am asking because I have a situation where when I run this from a visual studio project started in our development shell (which sets up a common build environment) I cannot get the web service to show up in the browser.
It starts the asp.net development server and creates a single file:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\c43ddc22\268ae91b\hash\hash.web
but when I start it from a stand alone project i get a whole slew of files in here:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\edad4eee\d198cf0e\App_Web_defaultwsdlhelpgenerator.aspx.cdcab7d2.vicgkf94.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\edad4eee\d198cf0e\service1.asmx.cdcab7d2.compiled
etc etc
I am trying to debug this but not really getting anywhere. i have inspected the output from VS but the only option I get is for the build output, which is basic and doesn't really contain any information that is useful. I have tried running both versions with DebugView running but no output there either.
I would like to know if there are any log files I could look at, or if anyone has any suggestions on how I might be able to debug what is going wrong here?
For completeness the output I get when it doesn't work is:
Parser Error
Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.
Parser Error Message: Could not create type 'WebService1.Service1'.
Source Error:
Line 1:
Source File: /Service1.asmx Line: 1
Version Information: Microsoft .NET Framework Version:2.0.50727.3603; ASP.NET Version:2.0.50727.3082
Ok, not sure that its perfect but I found a resolution to this issue. the problems seems to be that the development shell redirects the <OutputPath> of the projects visual studio is building, and this was causing problems as, although the dependencies of the web service project were being copied into the $(ProjectDir)Bin\ directory, the actual webservice dll itself was not. The solution (workaround?) seems to be to add this to the post build event command line:
xcopy /y "$(TargetPath)" "$(ProjectDir)Bin\"
Then i am able to right click on the .asmx file and select view in browser and everything works as expected.
Hope this might help someone else in the future. or maybe even me in another place and time.