I am trying to set up references to the CRM 2011 sdk
Microsoft.Xrm.Sdk.dll
Microsoft.Xrm.Portal.dll
Microsoft.Xrm.Client.dll
While trying to use the CrmSvcUtil.exe to generate the early bound types for CRM, I get an error Microsoft.Xrm.Client.CodeGeneration.dll cannot be located. I could not locate the dll in any of the packages that I downloaded using Nuget PM.
Can anybody advise on the usage and how to obtain this?
Use the Early Bound Generator in the XrmToolBox Tool Store. It contains the functionality to generate code using the Xrm.Client. Or if you really just want to use the DLL and do everything by hand, it contains the DLL in the download.
Update
As of March 2020, the EBG no longer supports the deprecated Microsoft.Xrm.Client usage. Hopefully you've transitioned off of that. You can still download older versions of the EBG on NuGet if you're stuck on that client generation.
Related
I am trying to download ibm.data.db2 in Visual studio 2019 nuget packet. But for some reason only ibm.data.db2.core is available but a year back ibm.data.db2 was available. Is there a way I can download the older version or core works?
It has been removed from Nuget for unknown reason. I am also trying to find one. I had to copy the DLL and add a reference to it to run an old project.
Fortunately, I was able to find an archive and yet another one.
The removal probably has to do with it being out of support. Did you need support for it? I did not too.
I'm trying to import an XML generated in MS Project 2016 into another system, but the XSD I have seems to be from an older version. I've only been able to find it for 2007 and 2010. I can probably tweak what I have to account for the differences, but it would be nice to not have to. Are schema definitions for newer versions of Project available somewhere?
Sadly I'm not sure they exist. I look for updated versions periodically but I haven't come across any yet.
The most recent version I have has the filename mspdi_pj15.xsd, and the comment in the file says Revision date: 2012-07-18. This was extracted from the Project 2013 SDK.
One word of warning is that regardless of MS Project version changes, the XSDs don't match what Project actually reads and writes in a few areas. I use the XSD to generate JAXB code as part of MPXJ, and I've had to make a number of manual revisions to the published XSD to get it work correctly. Unfortunately I'm not sure that publishing the changes is possible as the original file is copyright Microsoft and doesn't mention redistribution.
I wish this is a stupid duplicate of an already answered question.
I have a asp.net website that depends on some other projects (dlls copied to bin). Now, what I want is every time any of those projects are updated, I get latest dlls in my website/bin. I DO NOT want my CI server to check-in updated dlls.
I already have a private NuGet feed for my project, and just want it to serve the latest dlls after each successful CI build. Now, my questions are
Is there a way to directly serve the dlls, without creating nupkg? And probably pick them from build output folder? (for some reasons, it's not that convenient to create package as a post build task for all the dlls hundred times a day) If that is possible, awesome!
If not, can we avoid increasing version number of dlls each time, still make nuget update to the new dlls? Something like update based on latest publish date or something? (there is huge bunch of dlls, and lot of dependencies)
Is there a way to take latest dlls without building the solution? Yeah, I can do a nuget update command, but is there any other way?
Someone suggested mirroring my current code base and using something like MyGet or ProGet. For several reasons, that is not feasible at the moment.
Triggering a Visual Studio build after any NuGet dependencies is probably not quite what you really need - that's a job for CI. However, you can set the version ranges in your packages.config file to make VS (via nuget) pull newer NuGet packages when available.
To answer your specific points:
Why would you want to server 'random' loose DLLs whose origin you cannot be certain of? NuGet provides a mechanism to track the origin of code on which your own code depends, which makes tracking down bugs easier :) If you rely on NuGet packages containing DLLs which change 'hundreds of times a day' then you should likely just build those DLLs directly with your application.
See #1 - if you are re-building NuGet packages very often, then you likely have your package boundaries wrong. Consider how truly independent your packages are, and see if it would makes sense to bring some of the DLLs together, or even separate out (fork) code which is shared between multiple separate applications. If you create a new version of a NuGet package, then you should increase the version number - that's a fundamental premise of semantic versioning, and you'll get into a mess if you do not follow this pattern.
To bring down the latest NuGet dependencies, nuget update is your friend :)
Using MyGet or ProGet might be part of a solution, but it's not directly related to the patterns you mention above.
I have an old project that uses MPXJ library to access MS Project 2010. However it doesn't get the files save as Project 2010 format even if I uses the latest MPXJ 4.0. What else do I need to do to get the files of that format? I've searched MPXJ website but there seems to be no document about the changes and a tutorial to modify existing codes.
you should not need to make any changes to read Project 2010 files. The MPXJ API has not changed significantly with the 4.0 release: there are a few new Task and Resource attributes. If you are using the "presentation" information from the MPP file, you'll find that colors have changed from being represented by an enumeration to being Java Color types. That's pretty much it.
If you are still having specific problems reading Project 2010 files, feel free to raise a bug at SourceForge, or drop me a note directly.
Cheers!
Jon
Disclaimer: I maintain MPXJ
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.