|
Where do you think the framework assemblies come from?
|
|
|
|
|
I know where the framework assemblies come from. The point is that you should think carefully, two, three, maybe even 4 times before you put one of your own there. Unless its usage is pretty much global in scope and it is stable, it belongs in the directory with the application EXE with which it shipped. Since .NET assemblies tend to be pretty small, compared to many native DLLs, this is not such a burden.
|
|
|
|
|
Yes you should think before using the GAC as it's probably not a good solution if your helper classes are volatile. I didn't tell him to put his classes in the GAC, I simply suggested it as an option to think about if he hadn't already. He is in the best position to decide if his classes are suitable for the GAC, not me and not you either If it's good enough for Microsoft I'm sure it's good enough for us too.
|
|
|
|
|
I agree. My comments about the GAC were aimed primarily toward lurkers.
|
|
|
|
|
F-ES Sitecore wrote: He is in the best position to decide if his classes are suitable for the GAC, not me and not you either
Most of the time an application developer should not be putting anything into the GAC.
That doesn't mean no one should ever do it but rather that they should only do it if they find that other solutions are not applicable.
|
|
|
|
|
F-ES Sitecore wrote: Where do you think the framework assemblies come from?
And device drivers live in a special realm as well.
But that doesn't mean I should make my banking application into a device driver just because it is possible.
|
|
|
|
|
jschell wrote: But that doesn't mean I should make my banking application into a device driver just because it is possible.
Putting helper functions into the GAC could well be a viable solution, I was merely pointing it out as an option, I wasn't telling anyone to do, or not do, anything.
|
|
|
|
|
F-ES Sitecore wrote: Putting helper functions into the GAC could well be a viable solution,
Unlikely and still not comparable when referring to "framework assemblies".
The comment stands - most of the time it is not a viable solution to put anything in there.
|
|
|
|
|
jschell wrote: Unlikely
That's your opinion based on zero intimate knowledge of the OP's code. As I've already said, it's not for me or you to decide, I made the suggestion for the OP to look into so he can make his own decision.
|
|
|
|
|
F-ES Sitecore wrote: That's your opinion based on zero intimate knowledge of the OP's code.
I have more than "zero intimate knowledge".
I know the code is being used by humans and non-technical ones at that. And users are copying it between machines. Thus the conclusion is that this is some UI application tool.
And for the scenarios suggested it makes it much less likely that the GAC should be involved at all.
|
|
|
|
|
jschell wrote:
I know the code is being used by humans and non-technical ones at that. And users are copying it between machines. Thus the conclusion is that this is some UI application tool.
I don't think that is "intimate knowledge".
jschell wrote: And for the scenarios suggested it makes it much less likely that the GAC should be involved at all.
If he hadn't considered the GAC before at least it is something he can think about now and make that decision for himself.
|
|
|
|
|
F-ES Sitecore wrote: I don't think that is "intimate knowledge".
With my decades of experience and given the original question that does in fact, to me, provide quite a bit of knowledge about the most likely scenarios.
|
|
|
|
|
You don't have intimate knowledge of his actual code though so you don't know if it is GAC suitable or not. All you can do is guess at a probability which is all well and good, but that's not something you should use to dictate solutions to people.
|
|
|
|
|
F-ES Sitecore wrote: but that's not something you should use to dictate solutions to people.
I suggest that you re-read the entire thread.
|
|
|
|
|
No need
|
|
|
|
|
Bartosz Jarmuż wrote: - requires me to deliver a separate .dll file, which for some reason is much more difficult for users (they tend to share my programs without the .dll, which then crashes on startup)
As mentioned that isn't going to work regardless of what you do, because of the Net version dependency.
Bartosz Jarmuż wrote: I have a helper project which I use in all the applications that I create...I am the only person editing code
Where the plural "applications" means how many exactly?
And what size are the applications?
If there are only two or three and the apps are relatively small then don't use the dll.
If many applications or there are a few but big then use the dll.
The second case occurs because, despite your best intentions, it is more likely that you will break something by adding an improvement. Because of that handling the helper code as an independent delivery should continue to make you aware that changes can cause problems. And hopefully you should implement unit tests for the dll to insure that behavior doesn't change unintentionally.
The threshold for this becomes lower if another developer was added to the mix.
|
|
|
|
|
Hi guys, i am trying to do the auto complete textbox using entity data model but i am getting this error "parsererror" please help, bellow is my code:
aspx Code
<%@ Page Title="Home Page" Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="AutoComplete._Default" %>
<asp:content runat="server" id="FeaturedContent" contentplaceholderid="FeaturedContent">
<script src="http://code.jquery.com/jquery-1.9.1.js"></script>
<script src="http://code.jquery.com/ui/1.10.3/jquery-ui.js"></script>
<script lang="javascript" type="text/javascript">
$(function () {
$('#<%=txtCompanyName.ClientID%>').autocomplete({
source: function (request, response) {
$.ajax({
url: "Default.aspx/GetCompanyName",
data: "{'pre':'"+ request.term +"'}",
dataType: "json",
type: "POST",
constentType: "application/json; charset=utf-8",
success: function (data) {
response($.map(data.d,function(item)
{
return {value : item}
}))
},
error: function (XMLHttpRequest, textStatus, errorThrown) {
alert(textStatus);
}
});
}
});
});
</script>
<asp:content runat="server" id="BodyContent" contentplaceholderid="MainContent">
Auto Complete
<asp:textbox id="txtCompanyName" runat="server" cssclass="textboxAuto" width="350px" font-size="12px">
aspx.cs Code
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Script.Services;
using System.Web.Services;
using System.Web.UI;
using System.Web.UI.WebControls;
namespace AutoComplete
{
public partial class _Default : Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
[WebMethod]
[ScriptMethod(ResponseFormat= ResponseFormat.Json)]
public static List<string> GetCompanyName(string pre)
{
List<string> allCompanyName = new List<string>();
using (MyDatabaseEntities dc = new MyDatabaseEntities ())
{
allCompanyName = (from a in dc.TopCompanies
where a.CompanyName.StartsWith(pre)
select a.CompanyName).ToList();
}
return allCompanyName;
}
}
}
|
|
|
|
|
Hi guys, i got a solution it is okay now.
just needed to change "constentType:" to "contentType:"
|
|
|
|
|
I am implementing this for the first time, so need expert advise.
Following is what I am trying to achieve:
-- I have a dll which is called by the exe application from two different places. My aim is to not call certain loc in dll when it is called from the first location.
I don't think conditional directives will help as they would not compile the code. I want to skip loc at runtime based on the call from the application. Dll will have an overloaded function implemented to distinguish between the calls.
|
|
|
|
|
If I were you, I'd use Dependency Injection and have something in the DLL trigger the relevant registrations depending on which app you are using.
|
|
|
|
|
One way to do it is to put the "conditional" code in the called method: you can find the Assembly it was called from using System.Reflection.Assembly.GetCallingAssembly[^] so if the two calls can be in different Assemblies that's easy.
Or you could look at the calling method:
StackTrace st = new StackTrace();
string callingMethodName = st.GetFrame(1).GetMethod().Name; But they are both rather messy solutions.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Please correct me if it's a bad approach:
I was thinking to set a boolean flag variable/property in overloaded function. This variable/property can be defined in a common static class. Finally, use this flag to execute LOC selectively.
|
|
|
|
|
It's not nice - if you have to use a static, it's probably a bad design!
And what happens if you have multiple threads, now or in the future? The approach fails, perhaps very badly.
Instead, I'd provide an optional paramater:
public void MyMethod(...list of parameters..., bool fullMethod = false)
{
} And then only call it with the full version when I needed it.
Why are you trying to do this? It sounds as if you have control of the calling and called ends, so why do you need to complicate things this much?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Hypot.. hypohth.. hyph.. imagine it to be a brownfield
There is a succesfull application that suddenly needs branding; easily done, but what about the helper routines? Your executing assembly is not you. The calling one is not you. One needs to cater customer #1, the other a politician.
How do you distinguish the green UI from the brown one? Higher up in the tree of assembly references, how would you know whether to output green or brown text? If there's some intermediate shared assemblies, things quickly escalate.
So, if the stacktrace contains a reference to the entrypoint of the login, we know whether or not we are dealing with #2. If they are working on a licensing-scheme then all bets are off, offcourse.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I see nothing wrong with a static property, so long is its setter is protected by a mutex of some sort, which could be as simple as a lock ( object ) statement, where object is a private static object in the same class. (To avoid a deadlock, the object that gets locked must be separate from the property being set.) This is standard practice for a lazy initialized Singleton.
|
|
|
|