I had to change the xmltree.cs file and now i need to move the dll of the compiled code into another project to update the project. There are a ton of dlls in the presentation bin. I wanted to know if anyone would know which specific ones would need to be moved.
Thanks,
Corey
Assuming that you have created your project from the Umbraco source, you will need to get a clean set of the source (same version) and compile it without your change. Then make your change and recompile. The affected DLLs will have changed their modified dates, and these will be the ones that are dependent on your code change.
You should never base your project directly on the source, especially if you don't know what you're doing. If you need to modify the source, keep it separate (and under source control) and build your project on the compiled version.
Related
I am writing a very basic library in VB.NET
The library just contains classes and modules.
Now in built output I see this files
Application.Designer.vb
Application.myapp
AssemblyInfo.vb
Resources.Designer.vb
Resources.resx
Settings.Designer.vb
Settings.settings
Since I've seen other libraries with only AssemblyInfo.vb file, I was wondering if I can delete the rest.
What is the minimum of files I need here for the lib to work correctly, since I don't have any ressource or setting?
All the files you listed are necessary for a vb.net library project. And these files are generated (in My Project folder) when the project created not the build output files. So you need to keep all the files you listed in order to develop and build your project locally.
And for the files of build output, you can add these files in .gitignore.
When you create a project in VS, you select a predefined template that dictates what gets created. People often become accustomed to seeing the superfluous objects that a given template creates and assume that those objects are mandatory and must be there, However, much of it is not needed.
There is also the Empty Project template (the exact name of this template varies depending on the VS version used).
In VS2017, selection of the template would look like this:
This is a bare-bones project and the Solution Explorer will look like this:
As you can see, there are no pre-loaded references. You will need to add them yourself. About the only thing defined in this template is that you are using the VB language; This project starts out as a WinForm type, so go to the Project Properties->Application tab and change the "Application type" to "Class Library" since you want to create a library.
You may find it useful to start with an Empty Project and add the stuff you normally use and then export the project as new template (in VS2017: Project Menu->Export Template). For more on creating termplates, see: Creating Project and Item Templates
Edit: I just realized that I did not answer your real question about deleting the unused items. I just did a test case and deleted the items under MyProject. I received an error on deletion, but doing a clean/rebuild allowed me to proceed without issues. I would recommend that you backup the project before attempting this on an existing project, but I saw no long term issues in deleting unneeded objects from MyProject.
I have a vb.net application I'm looking to be able to distribute in the near future.
I'm not the original architect and the previous developer referenced a handful of .dll's that are under a GPL license.
All of the software that includes these dll's are freely available online, so my customer can go download and install them if they need that functionality. So I don't have to distribute the DLLs.
Currently they are referenced under the "Reference" part of the project file.
My question is, how do I resolve these dll's in a way similar to how the "references" dons it, but at runtime.
My plan is to search the registry for the location of these dll's and reference that location, but given the file location of the .dll, how do I "pull" that code into my project.
Thanks
You may try this
Search for Dll on specified path for dll
Use reflection to load assembly or dll into you code at runtime
Create runtime object from the loaded dll
Call required functionality from the dll
Reflection is the key solution to your problem that you may use to plugin new functionality into your project without distributing the dlls
This is the only solution that works
http://mylifeandsql.com/2018/03/26/replication-readpast-error/
also you can just start your migration with the following command
Sql(#"SET TRANSACTION ISOLATION LEVEL READ COMMITTED");
This will replicate dll changes like adding new column to a replicated table
You will also find that the column is automatically added to replicated articles > columns
No need to create a new snapshot nor set the sync to re-initialization ☺
Thanks
There is code that I want to include in most of my projects. Things like AFNetworking, categories for CoreData and unit testing, etc.
It seems logical to include all of these in a static library, and then use it in each project. I've noticed though, that many third-party libraries (like AFNetworking, and it's predecessor ASIHTTP) are included in projects by copying over all of their source files and then manually linking the necessary libraries to the project target.
This seems to me like the easiest way. It took a fair amount of time to figure out how to include an existing static library into a project. Even after I knew how, it still seems like a pain to do it for every new project. Also, the header search paths that you specify are to a local directory with the static library's files. Wouldn't it be easier, and is there a way, to copy the static library's files into the project? This is the same idea as including the class files directly like most libraries seem to do already, but it would be more organized because everything would be lumped into one library project, instead of having class files everywhere and having to include every one of them.
Static libraries feel like they should be the right way to go. Make a library that can be used with all projects that includes classes that every project will need. Makes sense. I am just conflicted because it seems like the right way to go is to leave everything out of a 'formal' library, and just copy over all of the class files instead.
I guess I am just looking for what experienced developers find to be the best option.
I would be among the first to admit that the process of referencing a static library in Xcode is not entirely intuitive. However, using a static library is the best option, without a doubt.
The main reason is maintainability: when you copy source code of a library to many places, you must remember to update all of them to the latest code when you upgrade to the next version of the library. This may be a rather error-prone process, especially when the underlying library source changes significantly (e.g. new files are added, old files are renamed, etc.)
There's a halfway solution - make an XCode project that builds your static library from source and put that into a shared repository (ie.. git submodule etc) which is included from each project's main repository.
Each of your projects would include this submodule and project. Then they get the latest source code each time they pull that submodule. If you set this up as a build dependency it will build a static library the first time you build and then XCode is smart enough just to include it each subsequent build so you get the benefit of fast build times.
You also get the advantage of having the source right there for stepping though / debugging.
If it's in a separate XCode project and a new version of a library adds or removes a source file you would only need to change that shared project - all your individual projects wouldn't change at all.
What about using CocoaPods? This tool does exactly what you want in a declarative way: you have a file (Podfile) where you declare your dependencies, and the tool downloads all the dependencies and builds a static library that gets added to your project.
I would agree that static libraries feel like they might be the correct way to go for a number of reasons, but can also introduce some issues.
The positives would be creating an easy way to add a library to a project. Although not completely intuitive, it is rather trivial to add a static library to a project after one does it a few times. Add the files, add the search path, done. This could also be useful in certain source control situations. Also, updating a library may be easier.
I think the real problem here is for the open source community. By including, say AFNetworking, for example, as a static library, you lose all access to the implementation files. This is a great feature of including source rather than a library. It lets you change code to how you see fit, and hopefully give back.
I'm trying to work with an existing home grown implementation of click-once. Currently we manually update the manifest for assemblies that we actually changed. I'm attempting to make it automatic based on a binary comparison of the existing assemblies and the newly built assemblies. Unfortunately, it seems that each time I run clean + build (automated build script) there are small differences to the assemblies, essentially invalidating the use of our click-once solution at all. I'm guessing that these differences are caused by some sort of guid generation or something along those lines. Is there anyway to prevent the differences in the assemblies?
And unfortunately, due to our branching/CI strategy I don't have the option of not cleaning because each release is from a new branch.
Otherwise, any suggestions on how I can compare two assemblies to see if any code has changed, without having access to the source code.
Thanks,
David
Typically, autobuild systems check the filesystem timestamps of the binary vs the source files (or object files vs source files, depending on the language). If the source is newer than the binary/object, a rebuild is triggered. This strategy may work better for you instead of actually diffing binaries/
I found BitDiffer a tool from www.BitWidgets.com that compares what has changed in an assembly. While this runs slower than a binary comparison, it removes the need to have MSBuild create an identical assembly.
Thanks,
David
First, I have a base assumption from watching Visual Studio compile things with its default .*proj files that, if you build the same solution twice in a row, it detects that nothing has changed and seems to fly through the solution build. Does this mean it knows that nothing was changed in a project and doesn't have to make a new DLL output?
If that's the case, I have a question. Say I have a solution with multiple class libraries, and an MSBuild task in each project that automatically increments the build's version by modifying AssemblyInfo.cs. Thing is (if my previous assumption is correct) it does this every time and triggers a new rebuild of each class library. Is there a target or property in MSBuild that can tell if the project needs recompilation, and skip my versioning step if so?
I ask because let's say I update project A, but not project B in a solution. If I run a build on the solution, I want it to update the version on project A, but since project B hasn't changed, I want to leave it alone.
Found something: http://msdn.microsoft.com/en-us/library/ms171483.aspx
MSBuild can compare the timestamps of
the input files with the timestamps of
the output files and determine whether
to skip, build, or partially rebuild a
target. In the following example, if
any file in the #(CSFile) item
collection is newer than the hello.exe
file, MSBuild will run the target;
otherwise it will be skipped:
<Csc
Sources="#(CSFile)"
OutputAssembly="hello.exe"/> </Target>
...that worked. But then got me thinking, what if someone pulls the code down from source control without the assemblies (which is how we do it)? Since it has no output to compare against, it'll do a compile and increment the version anyway. I think the complexities might lead me to abandon this approach.
It doesn't really matter if you increment on a developers box - what's important is that your daily/CI build is only incremented when needed. So, what I've done in the past is have some small XML file contain the next build number, and have an MSBuild task take this xml file and create a file called Version.cs (containing the versioning attributes you'd usually find in AssemblyInfo.cs).
Version.cs is never checked into your soure control - it's generated by the build.
Developers will sync the current XML file, build their binaries, and get the current version number. The continous integration build may also do the same thing. But a daily/official build will check out the XML file, increment the version information, and then check it in. From that moment on the version number has officially changed.
There are variations on this theme, but the general idea works.