Could not find file "C:\WINDOWS\TEMP\xxxx.dll - asp.net

Here is what I have tried:
Change the directory in which the temp files are stored. (Changed locally to each website).
Store the XMLSerialization object in a global variable and use that instead of creating a new one each time.
Delete all temp files in the windows temp folder.
Set permissions on the windows\temp folder (I have them set to everyone at the moment just to try and resolve the issue).
My Setup is as follows:
IIS7 on windows 2008 dedicated server.
The website is written in ASP.NET using Delphi.
I have several XML files that need serializing so not just one.
My website talks to the web service and processes the XML (I am guessing this is the part that is breaking everything)
Does anyone have any suggestions other than what is listed? I have read about using SGEN to pre-compile the serialization object but will this work for more than one XML file? I don't really know much about it.
Here is an example:
This is the code for one of my XML files. StockXMLSer is held globally and after testing is only created once per site.
function IntGetSTOCK_ITEMS(S: TStream): STOCK_ITEMS;
begin
if not Assigned(StockXMLSer) then begin
StockXMLSer := XmlSerializer.Create(STOCK_ITEMS.ClassInfo);
OutputDebugString('StockXMLSer Serializer Created');
end;
Result := STOCK_ITEMS(StockXMLSer.Deserialize(S));
end;

You will need to add some settings to your code in order to be able debug your serialization code. Please consult the following article on msdn.
Troubleshooting Common Problems with the XmlSerializer
Also there is a neat trick there that will keep the files created in your temp folder so you can see what is happening.
Under normal circumstances, the
XmlSerializer deletes the C# source
files for the serialization classes
when they are no longer needed. There
is an undocumented diagnostics switch,
however, which will instruct the
XmlSerializer deletes to leave these
files on your disk. You can set the
switch in your application's .config
file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.diagnostics>
<switches>
<add name="XmlSerialization.Compilation" value="4" />
</switches>
</system.diagnostics>
</configuration>
With this switch present in the
.config file, the C# source files stay
in your temp directory. If you are
working on a computer running Windows
2000 or later, the default location
for the temp directory is \Documents and Settings\\LocalSettings\Temp or
\Temp, for web
applications running under the ASPNET
account. The C# files are easy to miss
because they have very odd looking,
randomly generated filenames,
something like: bdz6lq-t.0.cs. The
XmlSerializerPreCompiler sets this
diagnostics switch, so you can open
the files to inspect the lines on
which the XmlSerializerPreCompiler
reported compilation errors in Notepad
or Visual Studio.

Just for the record, I had an error similar to this one and found the solution from this blog
After setting the permissions on the TEMP folder, the functionality that the error had started to work again.

XML Serialization creates a temporary DLL with the serialization code in it, somewhere in the temp directory. This is loaded into your App Domain when the serializer is created. It's possible that you are deleting this DLL when you clear the Temp directory, and for some reason, it's not getting regenerated correctly.

Related

Confused on what is the correct procedure on storing passwords in Web.config for Azure deployment

I've had a very frustrating experience on putting an MVC 5 app on Azure. I have been reading the following page: http://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure
But what I haven't managed to put in my head is the following:
Security Warning: Do not add your secrets .config file to your project or check it into source control. By default, Visual Studio sets the Build Action to Content, which means the file is deployed. For more information see Why don't all of the files in my project folder get deployed? Although you can use any extension for the secrets .config file, it's best to keep it .config, as config files are not served by IIS. Notice also that the AppSettingsSecrets.config file is two directory levels up from the web.config file, so it's completely out of the solution directory. By moving the file out of the solution directory, "git add *" won't add it to your repository.
And:
Security Warning: Unlike the AppSettingsSecrets.config file, the external connection strings file must be in the same directory as the root web.config file, so you'll have to take precautions to ensure you don't check it into your source repository.
The problem is the following: When I upload the Web.config file with the external files without being included I get hit by "The System cannot find the file specified", so for it to go away I must include the .config files defeating the purpose of Microsoft's post.
I really really really do not understand. I have added the connectionStrings and appSetting's keys in Azure's portal. What is the correct and secured way of putting my passwords and secrets online? What am I missing? Is it because I'm running in Debug mode?
According to this:
How can I secure passwords stored inside web.config?
There is nothing to worry about accessing the Web.config file...
But that just defies Microsoft's post.
Thanks.
I find the following technique to be the easiest way to do this.
Instead of putting the deployment values of these settings into the web.config, I keep the test values in there instead. I then put the deployment values into the Application Settings section of the Azure Website via the Azure Portal:
When the website runs, these settings will take precedence over what is in the web.config. This helps me avoid externalized files, allows me to keep sane development configuration that the team can share, and makes deployment very easy.
The best way is to set your secrets in the Connection Strings section of the portal. Any values set there will override values you specify in your web.config file.
This way they are only exposed to people who have admin access over the site itself. Having full access to the source won't even be enough to get the secret values.
More details here

customising web.config based on domain name

Most of my websites include one LIVE (production) and two TEST environments which are accessible via three different domain names e.g.
www.mysite.com
test1.mysite.com
test2.mysite.com
Each of the above are IIS Websites which point to the same physical versioned folder when they are all running the same version of the website.
What I typically do when releasing a new version is to place the new version into a new physical folder e.g. /inetpub/wwwroot/mywebsite/v41/ and point one of the TEST sites to that version of the site and test it. Once passed, the LIVE (and other TEST) websites are also repointed to the new version (e.g. v41).
Now my problem is this. Each website has its own database (TESTs have a copy of LIVE which can be refreshed via a couple of SQL BACKUP/RESTORE commands) however, the three sites are all "looking" at the same web.config file and therefore the same Database Connection Strings (either a System.Data.SqlClient or System.Data.EntityClient provider).
Is there any way that I can configure web.config to provide different connectionStrings based on the domain name/IIS website of the incoming request?
Maybe a tag or an attribute that qualifies a given tag?
I've looked all over for a solution but not yet found one.
Thanks in advance,
BloodBaz
there are two ways to manage multiple environment Specific Web.config file....
using t4 template,below is the link for that
http://ilearnable.net/2010/08/02/t4-for-complex-configuration/
VS Configuration Manager and create new "LIVE", "test1", "test2" build configurations for your project,check out the link
http://weblogs.asp.net/scottgu/archive/2007/09/21/tip-trick-automating-dev-qa-staging-and-production-web-config-settings-with-vs-2005.aspx
hope this helps..
why not split your config file up so connectionStrings.config is its own file. Then you can deploy everything and not overwrite that connectionString file.
where you normally would put the connectionString do this
<connectionStrings configSource="connectionStrings.config" />
Then create a file named connectionString.config
<?xml version="1.0"?>
<connectionStrings>
</connectionStrings>
Alternatively you can create another build option other than just release/debug. You can have web.config transforms that output a different config file depending on which one is selected.
I had a similar problem; I solved it by setting up all the database connection info in the same web config file, and then writing a handler that decides on the fly, based on the request and context, which environment it's in and uses that database.

How do I get multiple overlapping config files for multiple solutions in ASP.NET?

I'm very new to ASP.net, so I'm just figuring this out.
First off, I have multiple separate projects that will be hosted on the same server.
Second, they must be able to share certain settings (like connection string, configuration options, etc).
Third, those shared settings must be configurable for different deployments (test, prod, etc).
For example, I have two projects:
Project A
Project B
I have a setting called "Setting1" which should be accessible to both projects.
The value for "Setting1" should come from one of these files:
"TEST-config.xml"
"PROD-config.xml"
(There will be more than two config files, but I'll keep it simple for now)
And I want to have only a single place to change a single text file, which determines which of the *-config.xml files will be used:
"WhichSettingsFile.xml"
Here's an example of the file structure:
\WhichSettingsFile.xml
\TEST-config.xml
\PROD-config.xml
\Project1\Project1.csproj
\Project1\web.config
\Project1... (more files)
\Project2\Project2.csproj
\Project2\web.config
\Project2... (more files)
So currently, each project has a "web.config" like this:
<appSettings file="..\WhichSettingsFile.xml">
...
</appSettings>
Then I have a file "WhichSettingsFile.xml" like this:
<?xml version="1.0" encoding="utf-8" ?>
<appSettings>
<add key="SettingsFilenamePrefix" value="PROD" />
</appSettings>
And I have code like this:
public static string GetSetting(name) {
string filename = System.Web.Configuration.WebConfigurationManager.AppSettings["SettingsFilenamePrefix"] + "-config.xml";
// Open filename, parse as XML, get the values I need from it.
}
This means I can host both projects on Server A, set the WhichSettingsFile.xml to contain "PROD", and all settings will be read from "PROD-config.xml". I can do the same for the test server. And all those values are shared among the separate projects.
However, I need to be able to edit these files on the filesystem, and not have them embedded within the dlls / assemblies. When I run the project(s) from visual studio, the built-in asp.net hosting server will deploy the files to something like:
C:\Users\[username]\AppData\Local\Temp\6\Temporary ASP.NET Files\lskdjflskj\slkdjfsld\klsjdfwbe
But there will be no "WhichSettingsFile.xml" file since it's embedded in the assembly. Furthermore, the "PROD-config.xml" and "TEST-config.xml" files will not be included since they're not really part of the "code", and are not copied.
Ideally, I want to have this in the deployment folder:
C:\Users\[username]\AppData\Local\Temp\6\Temporary ASP.NET Files\abc123\Project1\(all the compiled files here)
C:\Users\[username]\AppData\Local\Temp\6\Temporary ASP.NET Files\abc123\Project2\(all the compiled files here)
C:\Users\[username]\AppData\Local\Temp\6\Temporary ASP.NET Files\abc123\WhichSettingsFile.xml
C:\Users\[username]\AppData\Local\Temp\6\Temporary ASP.NET Files\abc123\PROD-config.xml
C:\Users\[username]\AppData\Local\Temp\6\Temporary ASP.NET Files\abc123\TEST-config.xml
But I'm not sure how to do this.
So my problems:
-The "WhichSettingsFile.xml" is embedded into the assembly. I want this to be a plain text file on the filesystem that is referenced at runtime by the application. I realize I might need to avoid using for this. Is there a better way?
-I want to have multiple config files, also as plain text files on the filesystem.
I know what I've got is not working, and probably convoluted. But is there a better way to do this? Thanks!!
you can have a separate web.config per directory.
the root directory web.config will affect all sub folders. but values can be overwritten in sub folders with local web.config files.
you can add a new values with <add ... />, you can remove exist value set in global web.config with <remove ... />, you can clear all values in a section using <clear />.
http://weblogs.asp.net/mnolton/archive/2005/01/10/349986.aspx
If having separate directories doesn't fit with your architecture, you can store your configuration in a database, which is ideal in most scenarios as it offers caching, ability to change values w/out restarting application, sharing settings among multiple web servers, easier deployments (since you don't have to deploy files when changing settings) and so on.

Modifying Root Web.config in code

I would like to store some meta-information about a given site instance that can (a) be managed by that site instance and (b) persist clobbering of Web.config file.
The site will run in multiple environments (dev,testing,staging and production) and each environment can have different values for this metadata.
Note: All environments are running IIS 7.0+
The Root Web.config seems very appealing, as it is certainly outside of the website. Therefore, both files and databases can be changed while maintaining the metadata. I have seen how to modify the appSettings of the Web.config stored in the website, but is it possible to similarly modify the appSettings in the Root Web.config (Specifically within the proper directive)?
If you have other suggestions of approaching this problem, I would be very happy to hear them. Thank you!
would not use web.config for runtime modifications, that will cause the application to recycle, perhaps some other form of configuration file like app.config
if my assumption is incorrect and the web.config will not be edited after the application is started, then you can use WebConfigurationManager to access the file sections
Yes you can modufy the app settings within your web.config Just use the WebConfigurationManager class in the System.Web.Configuration namespace to create a Configuration object. This object could then be used to read and write changes to the web.config file.
You could then create your own "keys" or attributes that could be read as needed.
Depending upon what your attributes represent or if they need to be picked up by multiple environmnets from that server I would also look into making the modifications within the machine.config file as then those settings would apply to the enter machine and thereby picked up by multiple environments( if you are hosting multiple webapps from the server). This could save you time in modifying multiple web.config files and narrorw the storage or the metadata to one location vs. multiple config files in certain situations.

Compile asp.net web site and certain references are not being copied to Temporary ASP.NET Files Folder

Scenerio: I have an asp.net website that I am compiling successfully but keep getting an error in the browser saying that it can not find a referenced dll in the solution. I checked the directory in the Temporary ASP.NET File location and all of my referenced dll's are there except for the one it is failing to retrieve. I manually added the location it was looking for and the site worked.
The dll is referenced in code so it should have been moved to the temp folder. Does anyone have any idea why this would happen? I checked the properties on the referenced dll and copy local is set to true so it should be moved to the output directory.
Right click on the DLLs in your References/Bin directory in your project and look at the Copy Local property. Make sure they are set to True.
After hours of searching google and finding nothing, I decided to take a look at the actual properties of the dll file. To my surprise the issue ended up being permissions. For some reason the one dll that was beating me up all day needed correct permissions to be moved to the output folder. ughhh.
When you say "referenced in code" do you mean it's listed in the project file's Reference section? Or do you mean you are manually referring/naming it in your source code?
Have you tried this in your web.config (or higher up the config chain?)
<hostingEnvironment shadowCopyBinAssemblies="false" />
Where exactly are you expecting it to be copied? What is the path the error message is reporting?

Resources