I have some set of assemblies. I have disassemble those assemblies using the ISDASM.exe and change the namespace in the IL code and again compile those IL code using the ISASM.exe to get the assemblies without any error.
Here my question is after disassemble and assemble those assemblies product version, File version and the copyright information is lost. How can i add the File version and Product version after creating the assemblies.
But in the disassemble IL code all the version information are avaliable. But after compiling the IL code version information are not there.
Thanks,
Velu
By the looks of things, you'll have to create a version file resource, and include it with the /resource option.
Related
I've been using ABCPdf for a while. I originally installed it via the installer and plugged the license in during the installation. But now I'm adding the dll via Nuget so that I can build my solution in the cloud using MSBuild. And now I get the following love letter...
Could not find ABCpdf license. Attempt to insert license failed. Please see Manual Installation section of documentation.
Here it says do this...
XSettings.InstallLicense("cd9b5c07db69df2bf57c0a04d9bca58b10c44889c9fb197984e592f49addfce5ec5fe85d7b9205bc")
I added this line in on application start (although my usage of ABCPdf is in a different project) and I get the same error. Also, my license key doesn't look like this neat, single line of numbers and letters. It was supplied across multiple lines and looks base64 encoded.
Any ideas how to install the license when using Nuget installation?
The XSettings.InstallLicense call is correct.
If you combine all the lines of your license into one line and take everything between the square brackets, it should work.
I used an assembly redirect in web.config to point to the older version of the dll that was installed in the GAC. lol.
In my u-sql script I'm using the JsonExtractor that have a reference to "Newtonsoft.Json", in this script I also use a Custom Processor that uses "Newtonsoft.Json" too.
The problem is that the version used in the Processor is different from the version used by the JsonExtractor and it fails when load de dependencies of "Microsoft.Analytics.Samples.Formats.Json.JsonExtractor".
Is there a way to redirect assemblies?
Each U-SQL database can only contain one version of any given assembly. For example, if you need both version 7 and version 8 of the NewtonSoft Json.Net library, you need to register them in two different databases. Furthermore, each script can only refer to one version of a given assembly DLL. In this respect, U-SQL follows the C# assembly management and versioning semantics.
You can find more info here:
https://learn.microsoft.com/en-us/azure/data-lake-analytics/data-lake-analytics-u-sql-programmability-guide#requirements
In your custom processor just declare an alias for your version, and then you can use multiple dependencies by version. Is it possible to reference different version of the same assembly into a single project?
when i run in browser it gives error like Could not load file or assembly 'System.Web.Extensions' or one of its dependencies.
I am using asp.net version 2.0.50727
Please give the solution.
This is because you do not have install, or not include the Asp.Net Ajax. I am not sure what version are you use, but this is something that you know and you can get the appropriate files.
for example the version 1 is here.
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=883
I'm using a licensed version of Flex Builder Pro to develop an application.
I compiled the swc and generated swf successfully using ANT tasks.
It contains an Advanced Data Grid also. When this application is accessed, I get a runtime error and it fails to load.
TypeError: Error #1007: Instantiation attempted on a non-constructor.
at mx.controls::AdvancedDataGridBaseEx/getSeparator()
at mx.controls::AdvancedDataGridBaseEx/createHeaderSeparators()
at mx.controls::AdvancedDataGrid/createHeaderSeparators()
at mx.controls::AdvancedDataGridBaseEx/drawSeparators()
at mx.controls::AdvancedDataGridBaseEx/updateDisplayList()
at mx.controls::AdvancedDataGrid/updateDisplayList()
at mx.controls.listClasses::AdvancedListBase/validateDisplayList()
at mx.managers::LayoutManager/validateDisplayList()
at mx.managers::LayoutManager/doPhasedInstantiation()
at Function/http://adobe.com/AS3/2006/builtin::apply()
at mx.core::UIComponent/callLaterDispatcher2()
at mx.core::UIComponent/callLaterDispatcher()
I'm adding datavisualization.swc and datavisualization_rb.swc in the build paths.
How can I successfully compile the application without any runtime errors?
Please help.
Include the swcs in the library path as shown here.
Maybe this helps: http://kb2.adobe.com/cps/403/kb403121.html
By coincidence I had the same error a couple of days ago. The source of this problem was a library against I built, which was linked statically against an older version of the datavisualization libraries. Normally libraries should only be compiled against other libraries using the external-library-path compiler option, but this library was compiled incorrectly.
So that library contained older parts of datavisualization that were referenced by code in the library, while my code referenced newer parts from the datavisualization library itself. The result was a mix of older and newer datavisualization classes at runtime.
So check the SWCs that you include in your library path. You can extract these with a ZIP tool. You will then find a catalog.xml file in there. Search for mx/controls/AdvancedDataGrid in this file. In case you can see it included in the catalog, you've found the bogus library.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.