I have a ASP.NET web api project, the api has lot of dependencies to other dlls so we have placed all the dlls in a specific folder. If I point output path of the web api to that output directory and execute in IISExpress it gives following error
Parser Error Message: The CodeDom provider type "Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" could not be located.
If we see file location of the error it is still pointing to WebAPI_SourceCode_Directory\web.config and not my output folder. But output folder has web.config file. How can I make the web app to run from output folder using IISExpress
It is not recommended to change the output directory of an asp.net application due to IIS security restrictions.
However you can still hack your way through it by changing config files appropriately, see here
As per MSDN article, when you compile a Web application the compiled code is placed in the Temporary ASP.NET Files folder
To find this Temporary ASP.NET Files folder check my post here
do not use IIS express for development, use a proper IIS instead. This way you will iron out any production issues from the beginning.
Whether your API has a lot of dll dependencies or not, it makes no difference. The API needs to know where to get them from and I wouldn't change the default behavior. They will be in the bin folder like all the other dependencies when you build the project.
To deploy the API even in a local environment, use the Publish method to a local folder, then build an IIS application pointing to that folder.
That's all you need to do, so why complicate things? You can still publish in debug mode, you can still connect your Visual studio to it and debug it properly. There is literally zero need to fight the default way of doing things.
Related
Issue :
System.IO.FileNotFoundException: Could not load file or assembly
'Renci.SshNet, Version=2014.4.6.0, Culture=neutral,
PublicKeyToken=1cee9f8bde3db106' or one of its dependencies. The
system cannot find the file specified.
The Project is built on .Net Framework 4 which helps to transfer the files from local onto S FTP Server.
The Code works fine on my local machine without any issue,When deployed on the PROD server and run as per scheduled giving the error as mentioned above.
Let me know what exactly causing this issue.
If not installing from the gallery make sure the DLL is not marked as blocked. Windows will mark the zip and every file in it for security reasons and you will have to unblock them
Are you developing windows or web application? If web application, try enabling an option in IIS application pool -> Advanced Settings, "Enable 32 bit application" to true. This might solve your problem.
In case of windows or console application, select the reference Renci.SshNet dll and go to its properties and set "Specific version" to false.
After recently upgrading my .NET connector it gave the same error. I compile and run my app in VS and it works fine guessing because it copies all the MySQL NET assemblies to the exe folder so what I did is copied Renci.SshNet.dll to the directory of my exe and it worked. For some reason adding the path to the path system variable didn't help. Final solution was to remove the NET Connector and use mysqld in batch to do the selects and updates for the app.
Looks like you're missing the Renci.SshNet.dll.
In your project references you can edit the properties of Renci.SshNet. Make sure "Copy Local" ist set to true. It will copy the dll on build to your output directory (should be bin/Release).
I just rebuilt my WCF solution using VS2010 and uploaded it onto a Windows 2008 server with IIS 7.5 on it. For some reason, even after cleaning up Temporary ASP.NET files, restarting the server - http://www.mysite.com/myservice?xsd=xsd1 (and all other XSD files) show old schemas.
As a result my generated WSDL is no use.
I've found this discussion here: http://social.msdn.microsoft.com/Forums/vstudio/en-US/6a9e48e3-25ec-4859-abe4-2b0a335b23ae/wcf-service-wont-update
But I've tried discussed above things, and it doesn't work. I have a feeling there's something very simple I'm missing here.
Update: After a while I found this post (Update service reference not working), and when I moved my whole compiled WCF solution into a completely new AppDirectory, it broke with a "Could not load assembly xxxxx or one of its dependencies.
Then I checked my Fusion logs, and found this in one of the log files:
LOG: Assembly download was successful. Attempting setup of file:
C:\inetpub\wwwroot\my\path\to\lib.dll
LOG: Entering download cache setup phase.
LOG: Assembly Name is: XXXXXX, Version=1.0.4983.31160, Culture=neutral, PublicKeyToken=null
ERR: Setup failed with hr = 0x8007000b.
ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing terminated.
Workaround: So I wouldn't consider this a solution, but after
I created a separate solution - self-hosted WCF service host,
Added all my references in there (my WCF service library was among them),
Built the self-hosted solution,
Ran the self-hosted EXE on the server, and ran the Design Time URL in the browser.
Was able to see correctly generated WSDL and XSD files!
Threw the necessary DLL's into the bin folder of my ASP.NET App Directory.
Refreshed my browser and saw the desired changes in the XSD!
My guess is that when I started the self-hosted service, and ran it in the browser, the new DLL's got stored in some temp ASP.NET directory that I'm not aware of. Then IIS used the directory to execute the DLL's.
I would appreciate if someone could explain how in the world this works, and what is the right way to do it.
Solution:
So after all my troubles, here is what happened:
I use SVN for transmitting files onto the server.
When I ran svn up on the server, there was a conflict that I resolved with the old files.
Thus App Directory contained the old files, and the new files never made it there, because of the conflict.
I had a similar problem, and it was caused by the old version of the main service assembly lying around near the new one in "bin" folder. They got there together because at one point I renamed it and it started deploying with a new name, but the old one stayed where it was, and that was giving me intermittent errors about missing contracts.
Setup: MVC Web Api app, Visual Studio 2012
Folder layout:
D:\WebSites\MySite\bin\MyDLLBin\Some.dll
My application needs to LoadLibrary on an unmanaged DLL as part of a MVC Web API application. Before doing the LoadLibrary, I do a:
File.Exists(#"D:\WebSites\MySite\bin\MyDLLBin\Some.dll")
And this returns false which means I should not do the LoadLibrary.
I tried copying the DLL here:
C:\MyDLLs\Some.Dll
and
File.Exists(#"C:\MyDLLs\Some.DLL")
returns TRUE. So I do a LoadLibrary from there and everything is goodness.
I created the "C:\MyDLLs" folder by logging onto the server and creating it. The "D:\WebSites\MySite\bin\MyDLLBin" folder is created via Publishing from Visual Studio.
I think maybe some kind of permission problem, but I have logged onto the server and set "Everyone" to "Full Access" on every folder in the path "D:\WebSites\MySite\bin\MyDLLBin" and the File.Exists still fails.
It would be better for me to deploy Some.dll as part of the publish to the bin folder and not have to create a special folder on the server to hold the dll.
Can someone suggest a fix or some other things to try?
UPDATE #1:
Interestingly:
System.IO.FileInfo(#"D:\WebSites\MySite\bin\MyDLLBin\Some.dll").Length
does not throw an exception and returns 7132045.
Assuming that filePathInApp is the string holding the path to your file from the root of where the application is running (as opposed to the root of the file system),
Server.MapPath(filePathInApp) will alter your directory path to be "rooted" wherever the application is running. So you may want to try Server.MapPath("some.dll") or Server.MapPath("\MyDLLBin\some.dll")
I see many solutions to reading in values from an external configuration file in a C# console application, but I can't find a solution for my particular circumstances:
Due to reasons of deployment (mainly that this is for a console application that is packed for deployment as part of an MVC website using the Visual Studio web Publish method), the exe does not get packaged with its app.config file.
I'm dependent on libraries that make use of the ConfigurationManager.AppConfig["blah"] syntax, and I can't very well pass in my own AppSettingsSection to these libs.
My console application's .exe file is in the MVC app's bin directory. As both the website and the console app use the same config values, I was trying to simply load the site's Web.config file into the console app, but I haven't found a way of doing this.
The default configuration file is loaded once the AppDomain is loaded. For console applications, the configuration file must be located in the same place as the executable.
I believe that one possible solution is loading an AppDomain as a child of the console application and setting up the AppDomainSetup.ConfigurationFile property rightly to load the configuration file from the custom location, and then execute the whole console application's logic inside the child AppDomain.
You can use this AppDomain.CreateDomain overload for this case (the MSDN article contains a sample code on how to provide the AppDomainSetup):
http://msdn.microsoft.com/en-us/library/aehss7y0.aspx
As far as I know, you can't change the default behavior of where the executable AppDomain looks for the configuration file once it's loaded, but as I suggested you, you can create your own AppDomain with your own requirements!
I have a Visual Studio 2008 solution with an ASP.NET Web Application project. I want to change the default output folder, of said project, to $(SolutionDir)\WebApps\$(ProjectName)\bin. This I can do and when I build I get the expected assembly files in this folder. It doesn't copy the content files (aspx, etc.) to the parent folder but I have managed to fix this by hacking the project.csproj file with a custom build target.
The problem is I want to be able to debug this application using the ASP.NET Development Server, by pressing F5 in VS2008. Unfortunately the ASP.NET Dev server starts, has a "Physical Path", in the project directory rather than the parent of the output directory.
Is there any way to build my web application to a different output folder but still run the asp.net dev server to debug my site?
Thanks.
Short answer is yes, but it isn't pretty. The process I used is given below.
Unloaded the project in VS.
Manually edited the .csproj file to include a post build action that basically copies the content files (aspx, etc.) to the parent of the output folder.
For the debug options I set the project to launch an external executable. The Asp.Net Development server. Also manually set the url to launch.
What I learnt? I wouldn't do this, I'd just stick with the default and create an install/web deployment project instead.