How to convert PDB file to XML file? I tried the source from below, but it's taking exe as an input. Is there any opensource converter available?
The ISymbolReader interface from Microsoft needs a metadata token, which can be retrieved from the assembly using Reflection. I don't know a way to read the PDB on its' own - for my purposes, I always have the pdb and the assembly handy, so it hasn't been an issue for me.
Related
I have a Biztalk Service which calls other services. I have generated the XSD file from the WSDL file But unable to check-in the inhertied
XSD file in TFS due to the length.
I have manually map that particular solution to the minimum path in my local but still the schema name is too big.
If i rename the XSD which is dependent on other XSD which generates the error.
so is there any approch to solve this(Renaming of xsd giving error) ?
You mean path length?
Sure, it's very easy to just shorten the paths and or file names.
All you need to do is also update the Include/Import paths in the including .xsd. To do this, you will have to edit the .xsd in the Xml Editor, the Schema Editor has trouble with this.
I have used resource file(.resx) file in a class library project to store some error messages. When I set the "Build Action" to "Embedded Resource" for the resx file and deploy it works fine. But I would like to separate the resource file from the dll since I may need to change the error messages in resx file in future without the need to recompiling the class library project. I tried the other option in "Build Action" property Content,resource, etc but nothing seems to be working in the way I require. When I use these property I am getting the below error,
Could not find any resources appropriate for the specified culture or the neutral culture. Make sure was correctly embedded or linked into assembly at compile time, or that all the satellite assemblies required are loadable and fully signed.
Is there any way to resolve this error and make it work?
Resource files have to be set to embedded - that's how they work.
You can create another assembly containing the resources and reference it - this way you can redeploy the updated resources. It requires a bit more work in your code (loading the assembly in order to be able to get the embedded resources).
However, from your description (text messages that need to be editable after deployment), perhaps storing these in configuration is a better option (in particular if you are not localizing).
when i convert tiff file to pdf in debug mode it converted successfully but when i host it
on localhost it didn't convert and throw an exception:
Cann't make pdf files. Try again.System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {71DBCBF1-587B-42E4-9B30-74B80F4AA70F} failed.
why it happened.
please give any suggestion
Thanks
It would appear that the DLL you are referencing is not registered: http://support.microsoft.com/kb/201191
Check that the tool you are using is correctly installed, if it is a standalone DLL you may need to register it manualy (i.e. use regsvr32.exe).
i find this question tricky but what files store method signature info for xml webservice?
.dll, .asmx, .wsdl, .disco ?
TIA
It goes into a DLL once compiled, but it's in a code file when added to the project (referred to as a proxy class, it's in whatever language your project is). When you add a web reference it's imported this way. Updating the reference updates the .cs (or vb, whatever you're using).
If you want to see what happens, you can generate the code file yourself, see MSDN for details.
So overall: It is WSDL when fetched, converted to a code file when included (or updated), then finally compiled with the rest of your code into the DLL.
I am creating a method in a DLL that is going to be dropped into a web application.
The web application has a folder with a XML file in it:
/files/myfile.xml
My dll has to reference that DLL, but I can't hard code the path to the file obviously.
How can I reference that file and load a XmlTextReader with that file?
The best thing would be to have the path to the XML file be stored in a configuration file. Since both of your assemblies will be running in the same AppDomain they will both have access to the setting in the configuration file and you don't have to worry about hard-coding the path.
The simplest way that comes to mind would be to pass a filename parameter to the DLL's method from the web application. I'm sure you've already thought of this, but your question doesn't say what (if any) problems exist with that solution.